i think it would help many new potential users if 9front was at least mentioned (maybe near the link to 9legacy) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mc3ceb771617eacde8227343d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth hiro <23hiro@gmail.com>: > i think it would help many new potential users if 9front was at least > mentioned (maybe near the link to 9legacy) To begin with, I only run 9front, a fork of Plan 9. In my experience it's just enough different from Plan 9 from Bell Labs that it cannot be grouped with any releases of Plan 9 from Bell Labs with just a series of patches (as can 9legacy). However, I hope that this situation doesn't remain and that whoever is in charge of the Foundation and 9front can work to figure out how to make it so there's one distribution. That might be a pipe dream. Maybe that's already happening behind the scenes but my inner pessimist is saying "No." There appear to be entrenched philosophical differences, but both "sides" agree that 9front is a fork and 9legacy isn't (one point of view is described @ http://9legacy.org/intro.html and the other is @ http://fqa.9front.org/fqa0.html#0.1 ). So given that 9front is a fork, I don't think that the link to 9front should be mentioned next to 9legacy which is under the "Download" section. That appears to be mainly for Bell Labs-related releases. rmiller's rpi4 is really just implementing a kernel for rpi4, but otherwise the rest of the system is left untouched. I think (but do not know for certain) that 9legacy and the rpi4 source links will go away when there's a new release. Instead of under "Download", the link for 9front should at least be placed under the "Related Resources" section. In my understanding, the Foundation is limiting itself to focusing on what came out of Bell Labs and not different systems that have heavily modified it since. For example, I don't see HarveyOS, 9atom, Akaros, JehanneOS, NIX, Plan B, or Clive are linked either. Yet all of those I could see as being listed under "Related Resources". I actually like the listing and short descriptions found at http://fqa.9front.org/fqa0.html#0.1 (under "The United States of Plan 9"). With a few minor wording changes, how about using that list? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M19aca5ea58732c93b8700201 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Correct me if I'm wrong, but I don't think anyone had any issues with 9legacy taking functionality from 9front, vice versa. So both contain parts of each other anyway. How is 9legacy "more Plan 9", but 9front isn't at all, then? Makes no sense to me. Would a mention of a practical fork/distribution/whatever-you-wanna-call-it really hurt someone's ego that much? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M9ef7044854cc86fce96a1896 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Sigrid Solveig Haflínudóttir <ftrvxmtrx@gmail.com>: > Correct me if I'm wrong, but I don't think anyone had any issues with 9legacy taking functionality from 9front, vice versa. So both contain parts of each other anyway. > > How is 9legacy "more Plan 9", but 9front isn't at all, then? Makes no sense to me. Yeah, I don't think there are any issues with cross fertilization of ideas or code. But I don't think that means they're then equivalent. But a fork is different than set of patches. When 9front is self-described as a fork of Plan 9 (from all accounts I've read), isn't that separating from the Plan 9? All the forks I can think of off the top of my head (LibreSSL and BoringSSL from OpenSSL; OpenBSD from NetBSD) certainly share code, but remain separate. In the latter, I can think of PF that was incorporated into NetBSD from OpenBSD even after the fork. Isn't that similar to what you're describing? > Would a mention of a practical fork/distribution/whatever-you-wanna-call-it really hurt someone's ego that much? I don't know the answer to that question: it's not my ego. But from what I have read on this list it's not just ego that is involved. As I wrote in my last e-mail, I want 9front to be listed on the p9f.org page. But I'm a nobody, so I'm probably not going to persuade anyone. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mae74961461cbd11cc116c9ee Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Eish! I really can't resist, can I? On 6/24/21, Romano <unobe@cpan.org> wrote: > [...] But I'm a nobody, so I'm probably not going to persuade > anyone. > Let me try and keep this short, but it won't be easy. Firstly, this is not intended as an offence, particularly against Romano, it is merely an alert against our poorly understood "human nature". The sentiment implied in the sentence above is a bare-faced lie. Romano, you need not defend it, I utter lies like this daily, multiple times, and I spend my time mostly in solitude :-). Thing is, we try hard to be tactful or diplomatic and fail to be convincing because we don't actually know how to respond to similar falsehoods directed at us. My own problem is that I have no scientific foundations for what follows, only personal experience in a context where multiple natural "languages" flow freely and misunderstandings are more the norm than the exception. Here, we continue to pay a high price for not having resolved this madness at birth. 9front got off on a bad footing, in my recollection more a generational clash than anything caused by one or more technical issue. Repairing the burnt bridges requires undoing all the antagonism that has been accumulated since, plus more than just a smidgen of technical savvy. But the emotional need for approval did lead to acrimony and acrimony led to the eventual 9 fork and today one can still run 2Ed applications on 9legacy (bar occasional mishaps - not that I can think of any), but not 9front applications without modification. That, is a very clear ring-fence. And it makes me quite sad, but realistically, it would take quite a lot of tolerance, effort and time to merge the two streams and something would undoubtably be lost in the process of compromising. Not least, there would be ego damage (I have my own skeletons I would not want to release from the cupboard next to the one implied above). The point of the above is simple: only a neutral party can put Plan/9/Front together again and there are more pressing issues for the average participant to address that stand firmly in the way. Harping on the politics is the wrong thing to do, eventually survival of the fittest is going to dictate the path that will be taken. And the fittest, accidentally or intentionally, in the current ecosystem, in my opinion is plan9port, at least until Torvalds stops dictating the path Linux takes: our culture can't resist a strong personality (that's the "cult" in "culture"), but also cannot survive without continuity, surprise, surprise. The democracy that may favour intellect over emotion needs to be an artifact able to adjust to changing contexts, consciously. The Plan 9 Foundation may or may not have that in its genome. Miller is a reminder that a port to a different architecture is the product of both individual genius (and, yes, Cinap does that, also, I don't mean to be disrespectful) and sound foundations. What Plan 9 needs is a Nemo to redo his analysis of 3Ed and offer a more modern version focused on Plan 9 as the glue between the MS-Windows/Apple user interface (based on a perceived and certainly not genuine security) and the scrappy Turing machines Intel and co-conspirators are foisting on us. And to be ready for the next generation of hardware that may prevent this generation producing an Atlantis-sized civilisation collapse. Of course, that's not to suggest this must be Nemo's retirement package, it means that the right calibre of humans must undertake to perform such an analysis to its completion. Lucio. PS: I would have liked to bring Minix-3 into the rant above, but I have yet to explore to my satisfaction what it really represents. Suffice it to say that it may be able to run p9p and that is rather an interesting curved ball. The other oddity is the smart mobile computer we like to call a "phone". Why is there no Plan 9 flavour running on at least some flavour of it? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Me1fe9703569c5c6466229207 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Lucio De Re <lucio.dere@gmail.com>: > On 6/24/21, Romano <unobe@cpan.org> wrote: > > [...] But I'm a nobody, so I'm probably not going to persuade > > anyone. > > > Let me try and keep this short, but it won't be easy. > > Firstly, this is not intended as an offence, particularly against > Romano, it is merely an alert against our poorly understood "human > nature". > > The sentiment implied in the sentence above is a bare-faced lie. > Romano, you need not defend it, I utter lies like this daily, multiple > times, and I spend my time mostly in solitude :-). No offence taken. I don't agree with you. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M7b83cd0b11919bf0a20f7df1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On 6/24/21, unobe@cpan.org <unobe@cpan.org> wrote: > Quoth Lucio De Re <lucio.dere@gmail.com>: >> On 6/24/21, Romano <unobe@cpan.org> wrote: >> > [...] But I'm a nobody, so I'm probably not going to persuade >> > anyone. >> > >> [ ... ] >> >> The sentiment implied in the sentence above is a bare-faced lie. >> Romano, you need not defend it, I utter lies like this daily, multiple >> times, and I spend my time mostly in solitude :-). > > No offence taken. I don't agree with you. > Well, that was easier than expected :-) Thank you for the assurance. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mf6dbc0868d718f85449007cb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
I don't think the touchscreen technology has figured out how to distinguish between fingers yet. The rio environment would need to identify if you were using finger 1, 2 or 3 to tap on something so it would know if it was to move or resize the window, which context menu to open, etc... Either that or you would need to replace rio with something more touchscreen-friendly, in the process losing much of what makes the Plan 9 environment as unique as it is from a user interface perspective. Most "modern" phones also lack a suitable keyboard to provide reasonable interaction with the command line (and it can be difficult to type efficiently on something that small anyway). On 6/24/21 12:06 AM, Lucio De Re wrote: > The other oddity is the smart mobile computer we like to call a > "phone". Why is there no Plan 9 flavour running on at least some > flavour of it? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M84bef267275597c3ab44884a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
fde101@fjrhome.net: > Either that or you would need to replace rio with something more > touchscreen-friendly, in the process losing much of what makes the Plan > 9 environment as unique as it is from a user interface perspective. > > Most "modern" phones also lack a suitable keyboard to provide reasonable > interaction with the command line (and it can be difficult to type > efficiently on something that small anyway). Inferno can work quite comfortably with a touchscreen and a virtual "bitsy" keyboard. It's a different user interface from rio, but not horribly worse. Likely Plan 9 could be adapted to do the same. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T93744379e79c6971-M02879a98ecf562634ea3842d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On 6/24/21, Richard Miller <9fans@hamnavoe.com> wrote: > Inferno can work quite comfortably with a touchscreen and a virtual > "bitsy" keyboard. It's a different user interface from rio, but not > horribly worse. Likely Plan 9 could be adapted to do the same. > And handwriting may have been discarded in the recent past, but it can be brought back if, say, speech recognition won't work. We've moved on and Plan 9 can catch up. If not, then I think obsolescence looms large. But I don't think so, I think it just needs the ability to absorb lessons from the ecosystem. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T93744379e79c6971-M5fa24cba9e3d66a7f8ff253a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
I wonder if this could be copied from how plan9port behaves on macOS for instance. Using a single tap and then toggling/chording using alt and command keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could help to identify which modifier/button it translates to. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Frank D. Engel, Jr. <fde101@fjrhome.net> schrieb am Donnerstag, 24. Juni 2021 um 10:24: > The rio environment would need to identify if you were using finger 1, 2 > > or 3 to tap on something so it would know if it was to move or resize > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma226d19a1eea70cb2dc82b62 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> Foundation and 9front can work to figure out how to make it so there's > one distribution. For 9front this doesn't matter so much. We do not have a problem with there being multiple (sometimes experimental) distributions. For non-experimental things like 9legacy and miller's rpi releases, we're already benefiting from each other and sharing code without any issues. > There appear to be entrenched philosophical differences, but both > "sides" agree that 9front is a fork and 9legacy isn't (one point of > view is described @ http://9legacy.org/intro.html and the other is @ > http://fqa.9front.org/fqa0.html#0.1 ). I disagree here. When 9front was created it was technically a fork, because there was still a diverging bell-labs plan 9 distribution. We may seem to have new non-accreditated "management", but we are all fascinated what Plan 9 brought to this world and we would all like to build on the general wisdom of the Plan 9 philosophy. Now that bell-labs is gone, there have been no more mainline plan9 releases. Instead we have a few remaining relevant distributions like 9legacy or miller's rpi releases, all of which technically are about as much a fork as 9front is. Erik's 9atom has been unmaintained for a longer time so we didn't have any problems following those patches. Harvey and related distributions are highly experimental, they diverge much further from Plan 9 basic architecture without any will of keeping backwards compatibility. They are more revolutionary than some of us can stomach. A lot of people from the old crew at bell-labs completely abandoned mainline bell-labs plan9 even before 9front has been started because they seem content with just having a p9p layer on top of their macbooks or other unix machines. Apart from the occasional trolling that keeps on coming up on this list, I don't see what deep trenches people are imagining would impair the Plan 9 Community from working together on a well maintained Plan 9 distribution with simple procedures for sharing code in all directions. Whose wrong foot did you suffer from when 9front got first made? The few remaining people that actually care about collaborating together and keeping Plan 9 alive as a proper operating system running on real hardware, please add your views in case I am ignoring some other side of all this. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M439abc986009d978dc66f867 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Hello all, Klong mail incoming. I hope my English is ok and I don't tread on other's toes.) from my perspective it looks like this: There are multiple Plan 9 forks kor distributions). They all are philosophically and technically different, but they still share patches (even if many people don't know). This is fine. It would be great to have some kind of compatibility. i'm not necessarily talking about binary/ABI compatibility, but network compatibility, shell scripting and usability. People are actively working on it. I personally have no reason to run 9legacy in my network since 9front has everything I need, but other people do. The community is split into multiple different areas. Some areas are open to communicate with others, some actively work together and some are very "unique": you don't really hear from them in most channels, besides some email here and there, but that's it. I can name #cat-v, #plan9, ##9fans (bridged to discord) and the 9fans and 9front mailing lists. P9f is some very special case: They have the rights to the original codebase, they stare noble goals, but they seem to actively hide the fact that 9front exists. Hardcore 9front people don't really care about that, but the community (and I) do. I consider it really sad that 9front seems so cut away from the Plan 9 history just because some people try to hide it. Many people asked about mentioning 9front on the p9f page. When p9f started they told us that they focus on more important stuff first (which I can totally understand). Some activities (also mentioned at 9front.org/who/p9f) make me think that they just don't want 9front to exist. They state they want to push all stuff in the plan 9 family (9p, plan9 with forks, inferno), but they seem to actively promote 9legacy (which is fine, it's the most original continuation of plan9) and hide 9front (which is just sad). This is especially sad since 9front is probably the most modern and most active Plan 9 system currently existing. I just hope we all find a way to still respect each other and to grow as a community. Misunderstandings happen as well as lots of other human factors. My long 2 cents sirjofri Disclaimer: I actively used the original Plan 9 4e, Plan 9 on rpi, inferno, and I am an active 9front user. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M0a6e0197e217adff3f184fd7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Philip Silva via 9fans <9fans@9fans.net>: > I wonder if this could be copied from how plan9port behaves on macOS for instance. Using a single tap and then toggling/chording using alt and command keys. Maybe on a multi-touch input the distance of the 2nd and 3rd finger could help to identify which modifier/button it translates to. What I did with my Pinephone, but not run directly. I ran drawterm. I mapped the hardware vol up/down buttons to buttons 2&3. That gave me some chording ability (with 1-2 and 1-3), and simple keypresses for 2 & 3 (no swiping with 2, or swiping with 3). It didn't seem too odd. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Mbe4fa7cadb978896acecdb8d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Thu, Jun 24, 2021, at 11:12 AM, Philip Silva via 9fans wrote: > I wonder if this could be copied from how plan9port behaves on macOS > for instance. Using a single tap and then toggling/chording using alt > and command keys. Maybe on a multi-touch input the distance of the 2nd > and 3rd finger could help to identify which modifier/button it > translates to. Doesn't P9P do something more than this on macOS already? I recall something about some multitouch arrangements as a replacement for chords. Some pro users liked it very much, but I've forgotten what the arrangements were. Caveat: it might have been optimized for Acme only. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M959527dd82998773b268d056 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth hiro <23hiro@gmail.com>: > > Foundation and 9front can work to figure out how to make it so there's > > one distribution. > > For 9front this doesn't matter so much. We do not have a problem with > there being multiple (sometimes experimental) distributions. For > non-experimental things like 9legacy and miller's rpi releases, we're > already benefiting from each other and sharing code without any > issues. So perhaps I should have said 'one code base under version control', not 'distributions'. That is, have a master branch and different branches for experimental things and for formal releases. I think getting 9front onto git is a good push forward in that direction, since the Plan 9 is released by P9F under the MIT license from git, too. > > There appear to be entrenched philosophical differences, but both > > "sides" agree that 9front is a fork and 9legacy isn't (one point of > > view is described @ http://9legacy.org/intro.html and the other is @ > > http://fqa.9front.org/fqa0.html#0.1 ). > > I disagree here. > > When 9front was created it was technically a fork, because there was > still a diverging bell-labs plan 9 distribution. > > We may seem to have new non-accreditated "management", but we are all > fascinated what Plan 9 brought to this world and we would all like to > build on the general wisdom of the Plan 9 philosophy. > > Now that bell-labs is gone, there have been no more mainline plan9 releases. > > Instead we have a few remaining relevant distributions like 9legacy or > miller's rpi releases, all of which technically are about as much a > fork as 9front is. > > Erik's 9atom has been unmaintained for a longer time so we didn't have > any problems following those patches. > > Harvey and related distributions are highly experimental, they diverge > much further from Plan 9 basic architecture without any will of > keeping backwards compatibility. > They are more revolutionary than some of us can stomach. > > A lot of people from the old crew at bell-labs completely abandoned > mainline bell-labs plan9 even before 9front has been started because > they seem content with just having a p9p layer on top of their > macbooks or other unix machines. > > Apart from the occasional trolling that keeps on coming up on this > list, I don't see what deep trenches people are imagining would impair > the Plan 9 Community from working together on a well maintained Plan 9 > distribution with simple procedures for sharing code in all > directions. Whose wrong foot did you suffer from when 9front got first > made? For one, not having fossil. The removal of fossil might be what some users cannot accept? The setup and wiki preserved at 9p.io talk about how to setup fossil+venti and yet that cannot be done on 9front--it was removed completely. I think I recall you saying it was bug-ridden and unmaintainable, but could be misremembering who said what. From what I can gather, there was a serious bug that was fixed in fossil after 9front forked, and yet there is no intention of including it back into 9front. Additionally, I didn't realize initially that there was only one kernel for both cpu and terminal in 9front, as opposed to two in Plan 9. (I like that there's only one, personally.) That makes a difference because of the documentation in each system on how to setup a server. Those are two things that I can think of off the top of my head. Philosophically, I think the 9front maintainers/developers are much more willing to chuck older code and to replace with new code. I have personally benefitted from this approach so I'm not against it. 9legacy is much more conservative. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma33a7ff5d2238a0c5a82a824 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 338 bytes --] All versions of Plan9, Inferno, derivatives, forks, et al are welcome on the Glenda continent. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma32a526a9ee3953b55afcc24 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2.1: Type: text/html, Size: 1007 bytes --] [-- Attachment #2.2: hpicgebfckhdkaia.png --] [-- Type: image/png, Size: 27590 bytes --]
[-- Attachment #1: Type: text/plain, Size: 850 bytes --] What’s Dorren continent referencing? Silas On 24 Jun 2021, at 22:25, Wes Kussmaul <wes@ReliableID.com<mailto:wes@ReliableID.com>> wrote: All versions of Plan9, Inferno, derivatives, forks, et al are welcome on the Glenda continent. <hpicgebfckhdkaia.png> 9fans<https://9fans.topicbox.com/latest> / 9fans / see discussions<https://9fans.topicbox.com/groups/9fans> + participants<https://9fans.topicbox.com/groups/9fans/members> + delivery options<https://9fans.topicbox.com/groups/9fans/subscription> Permalink<https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Ma32a526a9ee3953b55afcc24> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M7b4febdc7dfcb5246fa8f366 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 1621 bytes --]
I think there where two reported issues with fossil. On was a bug in ephermerial shapshots which could cause it to crash, this was fixed about 10 years ago but did exist for an embarassingly long time. The other was a design decision rather than a bug which was not well communicated. Fossil was designed as a write buffer to be used in conjunction with venti. It could operate as a stand alone filesystem to replace the single user kfs. However if fossil fills up - because more has been written to it than it can hold or because snapshots have been turned on without a venti attached, it will crash badly and can (I believe) lose user data. The third issue with using fossil and venti is it is not very performant, it was reasonable when it was written in the early 2000s but is slow compared to modern Linux filesystems (I don't know how it compares to cwfs or hjfs). I have been using fossil and venti continuiously since 2004 and tend to jump to its defence. Re different kernels As I have understood it (others may correct me) the difference between cpu and terminal kernels is only the value one global variable (cpuserver) in the kernel, and the list of drivers compiled in - traditionally there was no graphics support in cpu kernels for example. -Steve ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M105752d0fa6af0e964b6b87f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
steve@quintile.net: > However if fossil fills up - because more has been written to it than > it can hold or because snapshots have been turned on without a venti > attached, it will crash badly and can (I believe) lose user data. No, it won't lose data (except in the sense that incoming mail, for example, can't be stored anywhere while the disk is full). You can't usually boot from a completely full fossil, but if you have a fallback boot method (from a CD or USB drive, from a network, or a spare recovery fossil partition) you can then start a fossil on the full partition, and run snapclean and/or delete some files, and all will be well. Even if fossil data was damaged, you could recover with flfmt from venti if you had archiving turned on. Also, nowadays it doesn't actually "crash" ... it just becomes difficult to do anything when no fossil blocks can be allocated. If the fossil on a networked server is full, you may not be able to log into it because that would require some fossil blocks. But you can still recover from a client terminal, by importing its /srv/fossil and using that to issue a snapclean command, or a remove command to delete something. > As I have understood it (others may correct me) the difference between > cpu and terminal kernels is only the value one global variable (cpuserver) > in the kernel, and the list of drivers compiled in - traditionally there > was no graphics support in cpu kernels for example. I have a version of the 4e kernel which functions as either cpu or terminal depending on the setting of environment variable 'service' in plan9.ini or cmdline.txt. It requires only a handful of lines to be added in /sys/src/9/boot/boot.c to make that work. Nowadays kernel RAM is plentiful enough that there's no real reason to configure different sets of devices between terminal and cpu. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md2b7a8425ae0681a784e7451 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> it just becomes difficult > to do anything when no fossil blocks can be allocated Thinking a bit further about this: intuitively one might expect to be able to reboot using a local file system which is completely full, and use du and ls to find big files and rm to delete them, without the need to allocate new blocks. Something in the way fossil works, makes this impossible at present. I wonder how much work it would be to investigate and fix? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-Mdf35f73131f8dcb668365537 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On 6/24/21 7:29 PM, silas poulson wrote: > What’s Dorren continent referencing? > There are three continents in the digital world * Montaigne * Dorren * Glenda On the Montaigne continent, everything is done outdoors on the old information highway using these strange billboards called websites (pretty much the existing world); On the Dorren continent, outdoor spaces are supplemented by secure indoor spaces called "buildings," built with PKI construction materials and PKIDR methods (e.g. occupancy permits); On Glenda, the Plan9 assumptions prevail. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-M176398634e00d7431b515c56 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > it just becomes difficult > > to do anything when no fossil blocks can be allocated > > Thinking a bit further about this: intuitively one might expect to be > able to reboot using a local file system which is completely full, and > use du and ls to find big files and rm to delete them, without the need > to allocate new blocks. Something in the way fossil works, makes this > impossible at present. I wonder how much work it would be to investigate > and fix? I haven't studied how fossil works, so excuse this light chat. Couldn't fossil have reserved blocks so when it starts and it's full it can add those block and present the user to a recovery session? Just a console session printing the last file modified? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M386580fb9170872f973a9995 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote: > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > > it just becomes difficult > > > to do anything when no fossil blocks can be allocated > > > > Thinking a bit further about this: intuitively one might expect to be > > able to reboot using a local file system which is completely full, and > > use du and ls to find big files and rm to delete them, without the need > > to allocate new blocks. Something in the way fossil works, makes this > > impossible at present. I wonder how much work it would be to investigate > > and fix? > > I haven't studied how fossil works, so excuse this light chat. > Couldn't fossil have reserved blocks so when it starts and it's > full it can add those block and present the user to a recovery > session? Just a console session printing the last file modified? I don't think I will tell anybody a scoop, but it is what is present in traditional Unix filesystems where there is a percent of the storage preserved... but for root, user under which you are not supposed to log to the system in normal operation. This is probably the problem: since there is no privileged user, for "whom" to preserve/reserve these blocks? I imagine the alternative would be, if fossil reports full, that memory filesystems should be mounted on top of the system mandatory writable dirs so that the system will not block but normal booting will not be done but the program launched will be one requiring user to make room, crucial infos written in memory filesystems being copied back to fossil when done. But it is easier to implement when booting/rebooting, but more problematic if the system is running. Except perhaps that there will always be a memory filesystem mounted with rescue programs/scripts that the user can precisely use when the system is out of disk space, utilities that write nothing to disk (but just in their memory realm), in order to not paint oneself in a corner. FWIW, -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M6b1ac09a6f8c59ccbd5b2327 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Fri, Jun 25, 2021 at 05:17:39PM +0200, tlaronde@polynum.com wrote: > On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote: > > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > > > it just becomes difficult > > > > to do anything when no fossil blocks can be allocated > > > > > > Thinking a bit further about this: intuitively one might expect to be > > > able to reboot using a local file system which is completely full, and > > > use du and ls to find big files and rm to delete them, without the need > > > to allocate new blocks. Something in the way fossil works, makes this > > > impossible at present. I wonder how much work it would be to investigate > > > and fix? > > > > I haven't studied how fossil works, so excuse this light chat. > > Couldn't fossil have reserved blocks so when it starts and it's > > full it can add those block and present the user to a recovery > > session? Just a console session printing the last file modified? > > I don't think I will tell anybody a scoop, but it is what is present in > traditional Unix filesystems where there is a percent of the storage > preserved... but for root, user under which you are not supposed to > log to the system in normal operation. This is probably the problem: > since there is no privileged user, for "whom" to preserve/reserve these > blocks? I don't think there is need of superuser concept here. What I'm imagining, again, without having seen the source code, is something like this: The file system is formatted and data representing the structure of the file system are stored normally. At execution time, the file server check a flag stored in some place to see if the system is full. If not, the data is changed so the blocks are "hidden" and execution continues. If the system is full, the file system starts a console session presenting the last file edited. At the end of the session, if the number of free blocks is bigger than the reserved blocks, the blocks are "hidden" and execution continues. If not, the console session gives an error and continues. The flag can be turn on at the same place the error of file system full is triggered. Again, easy talk, I haven't studied the source and a lot of people have said in this list that fossil is very complex. Some times the complexity of a task results in a complex implementation. You can't screw 1000 screws in a minute without a mechanical tool. What I don't know jet is if the complexity of fossil match its features. At least I can df all partitions... adr. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M010365538d976d3e3c89f274 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> I don't think there is need of superuser concept here. What I'm > imagining, again, without having seen the source code, is something > like this: > > The file system is formatted and data representing the structure of > the file system are stored normally. > > At execution time, the file server check a flag stored in some > place to see if the system is full. If not, the data is changed so > the blocks are "hidden" and execution continues. > > If the system is full, the file system starts a console session > presenting the last file edited. At the end of the session, if the > number of free blocks is bigger than the reserved blocks, the blocks are > "hidden" and execution continues. If not, the console session gives > an error and continues. > > The flag can be turn on at the same place the error of file system > full is triggered. In a multi-user environment you can make the file system do something similar when the system is full, but instead of starting a console session, delete the last file modified and presenting the user an error. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M4987d580aea7ace04872c584 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --] Le ven. 25 juin 2021 à 17:19, <tlaronde@polynum.com> a écrit : > On Fri, Jun 25, 2021 at 02:12:07PM +0000, adr via 9fans wrote: > > On Fri, Jun 25, 2021 at 01:41:30PM +0100, Richard Miller wrote: > > > > it just becomes difficult > > > > to do anything when no fossil blocks can be allocated > > > > > > Thinking a bit further about this: intuitively one might expect to be > > > able to reboot using a local file system which is completely full, and > > > use du and ls to find big files and rm to delete them, without the need > > > to allocate new blocks. Something in the way fossil works, makes this > > > impossible at present. I wonder how much work it would be to > investigate > > > and fix? > > > > I haven't studied how fossil works, so excuse this light chat. > > Couldn't fossil have reserved blocks so when it starts and it's > > full it can add those block and present the user to a recovery > > session? Just a console session printing the last file modified? > > I don't think I will tell anybody a scoop, but it is what is present in > traditional Unix filesystems where there is a percent of the storage > preserved... but for root, user under which you are not supposed to > log to the system in normal operation. This is probably the problem: > since there is no privileged user, for "whom" to preserve/reserve these > blocks? > > I imagine the alternative would be, if fossil reports full, that memory > filesystems should be mounted on top of the system mandatory writable > dirs so that the system will not block but normal booting will not > be done but the program launched will be one requiring user to make > room, crucial infos written in memory filesystems being copied back > to fossil when done. But it is easier to implement when booting/rebooting, > but more problematic if the system is running. Except perhaps that > there will always be a memory filesystem mounted with rescue > programs/scripts that the user can precisely use when the system > is out of disk space, utilities that write nothing to disk (but just in > their memory realm), in order to not paint oneself in a corner. > FWIW in 9front you can jump into rc while booting and fix this sort of issue. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-Mec344f9c69bd216b67f824c4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 3645 bytes --]
On Thu, Jun 24, 2021, at 9:51 PM, unobe@cpan.org wrote: > > From > what I can gather, there was a serious bug that was fixed in fossil > after 9front forked, and yet there is no intention of including it > back into 9front. When I was involved with 9front, there was a dislike for Fossil because it's complicated. 9front core devs greatly valued being able to understand the entire system, but Fossil was a bit too much. Particularly, they didn't want to be responsible for maintaining a fork of Fossil too. Some people imported it & maintained it for themselves. Notably, mycroftiv ran quite a complex setup with a number of users on 9front+Fossil and was quite happy about it. I think he still does, but he no longer publishes CD-ROMs with his additions as he's changed his focus to the latest mathematical programming concepts. mycrovtiv's... fork? I'm not sure it constitutes a fork, but there is quite a large set of namespace tools in addition to 9front+fossil. "ANTS is no longer maintained and updated post 2020 but the iso is still available." http://www.9gridchan.org/ ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Md646adaede1124e9b486cf40 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
> FWIW in 9front you can jump into rc while booting and fix this sort of > issue. Sure, having an in-kernel file system with rc and some tools for file system exploration and repair is another alternative to having them on a spare partition or usb drive or whatever. One could even imagine a community 9p server in the cloud providing a FSRaaS (file system recovery as a service). What I was suggesting is that it would be simpler if we could just run things like ls, du, and rm from a completely full fossil, without having to reboot or switch into a special environment. It may be as simple as not trying to update file access times if the partition is full. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M1d945cfd3d40324c273d42c8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On Fri, Jun 25, 2021, at 5:45 PM, adr via 9fans wrote: > > In a multi-user environment you can make the file system do something > similar when the system is full, but instead of starting a console > session, delete the last file modified and presenting the user > an error. The last file modified could be the log file which documents what went wrong. ;) I thought this through years ago, it's an annoying problem. I think the current situation isn't too bad. If I remember right, it's much better than CWFS, but I don't remember too clearly. I do remember my early Linux experience, trying to arrange several 100-200MB disks in such a way as to have both Emacs and X installed at the same time. (Impossible!) I was also root all the time because A: I didn't know what it was, and B: non-root authentication was broken in that release of that distro and I didn't know how to use the patch disks. My tiny disks inevitably filled up and somehow I managed to deal with them. (It helped that I had no data to lose, having just lost everything I wanted to keep from DOS, but it was still annoying.) It was harder than dealing with a full Fossil because Linux had no ramdisk at the time, I don't think there were any live CDs, and Linux didn't yet support `init=/bin/sh`. I don't think I understood how to start it in runlevel 1, or maybe I did everything in runlevel 1 so when that went wrong, I had to do something else. Sometimes, I had to unplug all the drives but the root, edit the boot config to make a recovery system, plug the drives back in... etc. By comparison, booting a Plan 9 iso and mounting Fossil is very simple and easy! :D It's essentially the same as how I'd repair any OS with a full disk today. Wonderful things, live-CDs. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4ec62ed03a91d7a4-M0b4c16b88cb43f6182e94a8b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 319 bytes --] I'm working on rebasing ANTS onto 9front-master, with the intent of taking up maintainance. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T523d6e906a17a7cc-Me752f3cc22bb8ccd5a0bc381 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 811 bytes --]