Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote: > Fine my dude, you don't have to call us Plan 9, you don't have to want to use > our code. However I ask that you be mindful in how you talk to new users and > don't assume that they have this same level of care for authenticity and "pure" code origins as you. You should read more carefully what I replied to the new user. It had nothing to do with licenses at all. I drew a path which spares him the frustrations during the time where he gets used to the system. And using 9vx is one way to set one step after the other. I'm wondering why you don't adjust it so that 9front can also be run there. As far as I can tell from once experimenting the reason why 9front doesn't run are your extensions to the kernel interface. 9vx is by far a better more plan9-ish way to virtualize under linux. But thats your decision. The path I suggested is the simplest one at least I think so. It takes less than 30 min to have a running plan9 installation without any problems arising from file servers without the problems of networking or data exchange. If you really believe that the path I suggested was a bad one or isn't simpler than directly using on of the plan9 distros I would really be surprised. This new guy has to learn rc, acme, rio, about plan9.ini about mouse shortcuts in acme. And do you really believe doing this directly on 9legacy or 9front is simpler than by using 9vx ? If this guy reaches the 4.step he will find his own path to whatever fork he pleases. So where exactly was my reply mindless ? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M71a22bd1f90c60a96961d626 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote: > Are you interested in sharing code between your fork and us? If you have no > intention of making your fork freely available then I don't think there is really much of a point in having some sort of compatibility layer. Of course I am interested in contributing. As an example i patched aux/vga while testing my fork on different hardware 9legacy couldn't switch to vga mode and I got blank screens on six different thin client models. Sometimes caused by not recognizing PCI bridges but many times by the way mode selection happens in aux/vga. This is a problem thats not only affecting my fork but many forks. I wrote a patch which tries to find the next possible 32 bpp mode available in the bios. While preselecting a fixed mode in plan9.ini led to blank screens with this simple change you get a mode that is supported an lies next to your choice in the ini file. This works until now for all devices I tested. Only a small example. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M252ef88ca11ebfce7119ae06 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:32 PM, ori wrote: > it's a sad system that can't even host its own sources. If you are running a network for your work there is nothing sad about placing services on different OS'es. I'm using fossil-scm for about one decade had never problems it has nearly zero administration needs, an integratec ticket system, wiki documentation if you want to a web interface. When I decided to substitute CVS I choose fossil-scm and never regreted this desision. It has a BSD license and I'm grateful for this software. And using Linux as its host system is something you don't recognize. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1e5bff53873c27fb388e6645 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:01 PM, hiro wrote: > did you ever hear of the git implementation that ori has implemented? It was placed on the latest 9legacy CD and I'm not needing/using it. I'm using fossil-scm which replaced cvs for me. Fossil is running on a linux machine in my network and is remotly accessible from plan9. But the choice of a scm is a question of taste. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mdaa67e50520b81d782e013be Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 3:35 PM, G B wrote: > Then you are still driving a Benz Patent-Motorwagen built in 1885, which is > regarded as the first practical modern automobile instead of driving > something newer like a Mercedes Benz S-Class or Lexus or Acura since these > newer automobiles are not automobiles from your perspective? Is this some kind of shift working from 9front defenders ? If so perhaps you could exchange state information before you change shifts. If you use 9front that's fine with me do as you please I prefer the final plan9 release and I don't have to justify my decision. And I don't want my arguments. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc3b0cd4ec4f8c03885597e31 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 1:26 PM, hiro wrote: > at this point all you're doing is speculation at best, it's verbose and spammy, and full of untruths. I do not welcome it, please stop generating noise. You don't have to read nor to reply to my posts. The amount of noise you create exceeds mine by far. If you prefer this kind of conversation I don't have a problem with that too. I don't use 9front so spare me your lecturing this is not 9front's message board but 9fans. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Maeacb3484e14957786de7f7f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 1:11 PM, hiro wrote: > i mean contributing to the plan9 team. i don't share in your discrimination of 9front vs. non9front code. i bet if all of us can be gainfully employed to work on "real plan9" we can all stop contributing to 9front. please enlighten me who my future coworkers might be. who else is going to join the team? I don't discriminate 9front at all. What I'm trying to say is if we want contribute to each other we need a compatibility layer and the simplest choice is the final edition of plan9. Its well defined and well documented. There won't ever be a real plan9 interpretations satisfying all who are interested in plan9. My fork makes use of segments dynld I use a binary interface instead of 9p to achive higher performance regarding data transfer between processes and especially the framebuffer. I have a gui which is portable to linux, windows aso. I can compile my software for plan9 linux and windows without a single change of lines. I use wrapper interfaces to achive this and a preprocessor which produces C code for the compiler on the destination system. My users need shortcut keys so I have a further device which reflects keystates parallel to the operation of keyboard. All those changes differ from the concepts of plan9. My fork is making use of concept possible with plan9 but not really the plan9 way of doing things. I don't use fossil and others as my filesystem and I don't have a 9fat partition anymore. So how could we possibly agree on a real plan9 we can't. Each fork has its own use case and there is nothing wrong about this. I never asked you to stop 9front in favour of a real plan9 no one has the right to make such a demand any more. You have your user community and are doing a great job. If we want to share contributions between forks we need a compatibility layer if we don't want to we don't have to. I don't have a problem respecting any fork of plan9. I will give back to other forks as much as I take from them. And if I contribute code to plan9 than I will make sure that it doesn't make use of enhancements I am using within my fork respect the coding styles of such a compatibility layer if one is ever defined. The whole discussion is about interoperability between forks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M42e70cabcf18e8b68a5b30c7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 12:40 PM, sirjofri wrote: > For me, it's "all plan9 systems", which includes belllabs plan9, 9legacy, > 9front and so on. That's one of the reasons I name 9front "a plan9 system", > not "the plan9 system", because there are a few different distributions/forks. The reason why I'm distinguishing between the plan9 and systems based on is quite simple. The moment we agree on such a fact we have a way to exchange code bug fixes participate in discussions. By this definition everything that can directly compiled and run on the final release of plan9 is usable by all forks cause each fork will have means of porting from this "mothership" and if people from different forks discuss than we discuss about things part of this mothership. Its okay that each fork has different views for things outside of this definition but this would end the never ending discussions. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1595216f59332b3651b45df6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> if you notice missing copyright messages: please send a patch. i have no clue what is required, but if you represent freetype or truetype or can imagine their legal requirements, please help us out there. it will be highly appreciated. btw, i hear about this for the first time. This was an example and I didn't find the original licenses from freetype in the folder or in the code. Perhaps they got lost while porting this code to 9front. I don't represent freetype and never claimed to > huh? which files exactly do you have doubts about? Any files where I don't know who and how wrote it. Was is ported is it just a reimplementation. I didn't sit by your side when you wrote your contributions or sources. and most when not all files in your distro have no hints about the author or the copyrights. Or did I miss any special folder where you provide the information regarding authorship of your sources ? > to me plan9 is indeed a toy. i wish it was otherwise. though it's a > toy that is to me personally much more useful than most "professional" > software. Nothing wrong about using an operating system in this way. As long as I'm using my fork for my personal needs I call it toy tool the moment I have to deliver something to others I can't view it anymore as a toy. So as always you misinterpreted this sentence : I didn't name 9front a toy that would be rude 9front is used by users and the moment you distribute it its a serious work which everyone me included has to respect. I didn't call 9front a toy but the purpose of its use. You can of course use plan9 for any tasks you can imagine and not the system is a toy. I would be really surprised if a programmer mistook this statement of mine. > That is a lie. We never ignored the license that plan9 was placed > under - and it was the lucent public license, which is extremely > permissive. > We completely ignored the work done later (by others) around > dual-licensing the GPL bec. we don't consider that an acceptably > permissive license and we disagree with that philosophy. I already replied to this and said that I didn't know you used the LPL version instead of GPL. I didn't know that you made that clear Ron defended your actions too so that's something I made a false assumption. Sorry for that. > Do not contribute to 9front if you are not ok with the MIT license. To > me this is why 9front is useful, but everybody has different legal > interpretations, so i'm only sorry that you can not see it's worth. If I contribute to plan9 than this will be made with an MIT license and all necessary information so that others can use the code if they see fit and this is also valid for 9front you can but thats your decision. On Monday, 13 May 2024, at 12:05 PM, hiro wrote: > I don't think p9f has ever provided anything apart from that misleading website and some kind of money transfers to people that i don't know. They are the ones chosen by Nokia and make plan9 available with an MIT license thats more than enough. To be honest with the fact that they until now decided to just distribute the final release instead of contributing enhancements to the system itself. I'm sure the outcome of such enhancements and contributions would have started never ending discussions arguments from 9front. They preserve plan9 as of the final release and forks can take this as a basement with clean licenses. I'm grateful to their acting for what they accomplished and respect the fact that they didn't change anything till now. On Monday, 13 May 2024, at 12:05 PM, hiro wrote: > 9legacy has both 9front and 4th edition code, as you already said. and many other people contributed stuff to both 9legacy and 9front, and other forks. For my personal taste 9legacy has should restrict itself to bugpatches for the final release. Anything beyond that should be part of /n/sources. But thats my opinion. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me6f3d0b36f444b6ea666d4c1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote: > So, you could say, plan 9 from bell labs is the last released version, 4th > edition. The others (9legacy, 9front, ...) are also plan 9, just not plan 9 > from bell labs. I personally prefer to call my fork based on plan9. I didn't write or invent plan9. Nor is my version a replacement or a continuation of plan9 it is fork based on plan9. On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote: > And if people want just a continuation of the concepts (the concepts which > are commonly understood as "plan 9"), 9front is also one of those > continuations, same as 9legacy or any other fork that tries to live those > concepts. As I said before I view 9front as one fork of plan9 and one I'm respecting. You do a good job and people who use your fork surely benefit from your work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9e9f2a281196eedb3a94429f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 11:39 AM, hiro wrote: > are you contributing the team? and paying the team? If you asked me. I don't use 9front or any of your contributions why should I pay for or contribute to your team ? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mfd203382b8fd745cca9f025b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> I would make a big difference between what plan 9 is and what the licenses > are. Software doesn't care about licenses. People do (and they should!). > > So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who > knows... > > I guess I could say a lot more about that topic, but I guess that's enough > and you can puzzle everything else yourself. plan9 is simply the final release made by bell labs and now owned by p9f. Thats not my interpretation this is a fact. Everything beyond that point is a fork based on plan9. Everyone is allowed to derive his/her work from this provided version of plan9. 9front is a fork, 9legacy is a fork and there were other forks. I have my own fork. If tomorrow another one decides to fork plan9 than thats okay. 9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't accept this fact. You aren't the owners of plan9 and you don't even own the trademark plan9. Your fork is called 9front and its absolutely okay to fork from code with a license that allows this. Your fork based on plan9 is extremely close to the original. But that doesn't mean you are the continuation of plan9. The only thing we can agree on as fork developers is what is officially called plan9 as a basement for exchange of code ideas aso. Code that can be compiled and executed on the official release is one that can be exchanged. There is only one group on this messaging board which has a problem with this definition of plan9 thats 9front. You insist on being seen as the continuation of plan9 but you aren't. You could have become this by buying plan9 from nokia and the trademark or nokia could have chosen you to hand it over to you but they didn't. p9f owns plan9 and if they ever decide to hand it over to you than you become officially the owner and continuation of plan9 but this won't change the fact that meanwhile others have forked from plan9 and call themselves fork xyz based on plan9 and you to respect this. Why is it so difficult for folks of 9front to accept that they are providing a fork based on plan9. > [1] (I would be very careful with such bold words. I feel like 9front people > have heard this phrase a lot and it's probably very thin ice for a few > people.) > And so what ? Compared to the replies of some folks from 9front regarding simple questions there is nothing bold about my statements. This is 9fans and if you start the same discussions over and over again than you have to live with answers like mine. Neither you nor I own plan9 while people outside 9front have no problem with facts you have this problem. You can't just accept the fact that 9front is a fork like many others. You may do a good job for your users and many enjoy using 9front as stated many times here on this board but but you do your job others do their job and you are in no position to give directions to others. I respect your work continue with it but don't act as if you are the ones who are in possession of plan9 or can dictate directions you can't and I also can't. I'm fed up with the regularly disputes you search with people who don't want to use your fork. I'm not using it and nothing will change my mind. > About another topic: you mentioned that plan 9 is in use for commercial > products, and you explicitly mention german medical sensors. I've never heard > about that and I'd like to learn more, as well as about other companies who > actually use plan 9. > > Everything I always hear in the industry is that plan 9 is outdated and > nobody uses it and nobody wants to hear about it. I only know of a single > company that uses it (coraid), plus a few little projects by taw that could > evolve into commercial products. I am and have acted as an advisor for many of these projects. The license change made it attractive for such projects cause you can keep your code closed source. The only duty to fulfill is providing the terms of the MIT license. You don't have to make your technology open source like you would have to if you used Linux. Don't underestimate the potential. Another example for a tiny os which is wide spread is Xinu which no one would expect. Plan9 has advantages over other systems that makes it attractive. I can only talk about those projects I know but be assured there are millions of devices around which run plan9 without anyone noticing. Again for the x-th time : I don't have a problem with 9front. I don't use it but I respect your work. The only think I dislike is the never ending discussions about plan9 being dead and 9front being the only choice and the attitude in some replies to questions of people on this board in an harsh and aggressive way. The moment one asks about 9legacy or plan9 and one from 9front advices to use 9front without success many of 9front getting aggressive and thats not right. -- 9fans: 9fans Permalink:
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> I don't want to depend on anything. Your method is just adding other > dependencies to ghostscript if you start with ps, and other > dependencies, if not ghostscript, including C++ code that is inability > to port on Plan9, if you use pdf. > I don't have any dependences remaining you misinterpreted something. In the first time I needed some way to handle pdf files I had to connect to a linux machine in my network where the conversion from pdf to ps was done by using command line tools. The result of this conversion were first jpeg files afterwards svg files for which I wrote a renderer in plan9. The second step was to write a converter pdftosvg which works for pdf files I had to handle. No C++ no postscript interpreter. If you have to handle pdf files with embedded postscript than I wish you good luck. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mb94a807ef23009e0c91d9042 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote: > So, Ibrahim, I can not agree with your statement here. I missed that they combined LPL licensed code instead of combining GPL licensed one. Thanks for the insides and sorry for the late response. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcd9e17b18ec5bfa7a0b4c527 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> For the ghostscript thing, and for the record (noting that, in this > area, I have put my code-money where my mouth is): > > I too want to get rid of Ghostscript. The path adopted is the > TeX/METAFONT way with the following: > > - A PostScript interpreter can be, functionnally, divided in two > parts: 1) a general purpose language allowing computation but aimed > for images and supposed, finally, to produce primitive graphics > directives (fixed results); 2) a rasterizer to produce a matricial > image; Converting pdf and ps to svg and rendering svg is the simpler approach. During the first time I used this method I just added a linux computer to my network and made use of pdftocairo with svg export. The advantage of this method is that the resulting container kept page information and also all glyphs are embedded in the resulting svg file which than gets rendered by a tiny svg renderer. Substituting ghostscript with a new interpreter wasn't worth the effort in my case. By reading the pdf metadata you also can keep the outline and other information. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md9b6263712929d39588a677a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I was making fun of your bragging because you implicated more installs > equated to higher quality. I never said that more installs equate higher quality and I never said that the quality of your code sucks or my code quality is better. On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I trust that the licensing in 9front has been handled correctly. I have to make my decisions cause by distributing my fork I am the one who is liable. On Monday, 13 May 2024, at 8:22 AM, Kurt H Maier wrote: > Hope this helps, Yes it does. As it seems you used code licensed with LPL and made changes while avoiding the use of GPL licensed code which would have caused problems. On Monday, 13 May 2024, at 8:02 AM, Kurt H Maier wrote: > One by one we're getting rid of the third-party software -- I particularly look forward to the day we can finally ditch Ghostscript -- but in the meantime these accusations of license violations are misinformed and have no basis in reality. You don't have to ditch Ghostscript. You can provide this as a seperated download. The user of your system is free to download GPL'ed programs or code as he pleases. This won't infect other parts of the system which don't rely on the existence of such programs. On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I was trying to communicate that for the purposes of using hardware made this > millennia (as any "professional" would do), 9front clearly has better code > for doing so. I trust that the licensing in 9front has been handled correctly. I don't doubt that your fork runs on more systems out of the box compared to plan9 final edition. But with minor changes in the final edition of plan9 I also don't have problems to make my fork work on hardware made for this millennia. I tried your system on some thin clients and except for a few with bugs in the bios or in uefi and some issues with timer interrupts your system was also running. I respect your fork but I won't use it for distributed systems. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf4269410df19d9e1e7239526 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> You have apparently not read our licensing document at > /lib/legal/NOTICE, which explicitly names the terms of the original Plan > 9 code, and assigns the MIT license only to changes produced by 9front. > > As the labs-provided code has been made available under different > licenses, we have updated this to reflect the changes, from Lucent > Public License, through the GPL relicense, and then the MIT license. > At all times we've complied with the distribution requirements of all > applicable licenses. > 2. You may modify your copy or copies of the Program or any portion of it, > thus forming a work based on the Program, and copy and distribute such > modifications or work under the terms of Section 1 above, provided that you > also meet all of these conditions: > > a) You must cause the modified files to carry prominent notices stating > that you changed the files and the date of any change. > b) You must cause any work that you distribute or publish, that in whole > or in part contains or is derived from the Program or any part thereof, to be > licensed as a whole at no charge to all third parties under the terms of this > License. > c) If the modified program normally reads commands interactively when > run, you must cause it, when started running for such interactive use in the > most ordinary way, to print or display an announcement including an > appropriate copyright notice and a notice that there is no warranty (or else, > saying that you provide a warranty) and that users may redistribute the > program under these conditions, and telling the user how to view a copy of > this License. (Exception: if the Program itself is interactive but does not > normally print such an announcement, your work based on the Program is not > required to print an announcement.) > > These requirements apply to the modified work as a whole. If identifiable > sections of that work are not derived from the Program, and can be reasonably > considered independent and separate works in themselves, then this License, > and its terms, do not apply to those sections when you distribute them as > separate works. But when you distribute the same sections as part of a whole > which is a work based on the Program, the distribution of the whole must be > on the terms of this License, whose permissions for other licensees extend to > the entire whole, and thus to each and every part regardless of who wrote it. You really should read the GPL. Your changes were included with GPL'ed code even in the same file and not distributed as independent patches so the modified work as a whole got infected by the GPL license. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcbca2e6474097e0d12b334e9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The last post had some paste copy issues : There are many companies who double license code. As the owners of such code they are free to do this. Users can't relicense code as they please especially not GPL licensed code. If you download code that is GPL licensed you can't change the license to the MIT license. The only one who had the right to make a change of the license was Nokia they were the owners and they decided to do so after this bold action from 9front. If I'm wrong it would be nice if you tell me where exactly lies my mistake. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M08dd52c34338ab27c6590836 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote: > At no time in all this was there any evidence of incorrect behavior on the > part of 9front. None. Zip. Zero. Zed. They have always been careful to follow > the rules. > > Further, when people in 9front wrote new code, they released it under MIT, > and Cinap among others was very kind in letting Harvey use it. > > So, Ibrahim, I can not agree with your statement here. > 0.2.4.4 - PRAISE FOR 9FRONT’S BOLD ACTION, RE: LICENSING > > Any additions or changes (as recorded in git history) made by 9front are > provided under the terms of the MIT License, reproduced in the file > /lib/legal/mit, unless otherwise indicated. > > Read: /lib/legal/NOTICE. > > 0.2.4.5 - Everyone loves the Plan 9 license (circa 2021) > > In 2021, the Plan 9 Foundation (aka P9F—no relation) convinced Nokia to > re-license all historical editions of the Plan9 source code under the MIT > Public License. > > As a consequence, all of 9front is now provided under the MIT License unless > otherwise indicated. > > Re-read: /lib/legal/mit This is a citation of the current FQA and in older ones predating the relicensing by Nokia the same paragraphs were present. If those statements from the 9front documentation are correct than your MIT relicensing predates the moment where the owner of plan9 Nokia made such a decission. This paragraph regarding the "bold action" of relicensing appeard before the owners of the code made it available under MIT license. Please correct me if I'm wrong. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M87ce4c9f9e82fb2fa4b938f2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
libttf was one example and because it made its way into 9legacy i inspected it. > Are you implying that a majority of users are using Plan9 in a commercial > setting? That seems a bit absurd. > For personal use I think these license issues (if they do even exist) are of > no concern. I think you are greatly > exaggerating the possible issue here for your average user. I could tell you about more than two dozens of projects alone at german universities where plan9 was used in medical sensor devices. Calling something absurd which lies beyond your experience gives reason enough to not name any of those projects. > Again, I think in your situation of distributing hardware with plan 9 or > whatever, then it makes sense to do whatever your lawyer says. > I think advising against using 9front for every user on these grounds though > is misleading at best. Its not the lawyer who is responsible to avoid copyright issues its the duty of the developer. Not the lawyer gets sued but the one who distributes the system. Everyone is free to use 9front. But I won't use 9front for a distributed system because I don't have the legal certainty as with plan9. I know who developed plan9 and I know that Nokia owned it before they relicensed it. But I don't this trust in 9front code. And so I wouldn't advise others who make use of plan9 in ways like I do to use 9front. > Do you also remove the Lucida and printer fonts? These were released as part > of the original source but have interesting claims as to the ability to > redistribute them. > Do you also strip out the parts of ape that include ancient GNU utilities? > Are you running your system without a diff and patch? Of course I removed all fonts from the system. I have my own font library with scaleable vector fonts based on caligraphy. As I stated before I removed any GNU utilities ghostview postscript page and all tools which have clearly GPL licenses are removed. Patch and diff are replaced with BSD licensed versions taken from OpenBSD. Those are the rules. > And Java runs on a billion devices. And I can't distribute Java, Linux, commercial operating systems because those can't be distributed as you please their licenses don't allow distribution as the MIT license does. > I'm quite curious as to your definition of "professional" in one where none > of the work done by 9front would be seen as beneficial. I can assure you I respect your fork and the state you reached. Professional use as a distributed operating system needs legal certainty. If you include code from sources and I use your fork than I am the one who is doomed not you because you are no legal entity. I have to make sure that my distributions has no legal issues. The way you answer to such licensing problems makes clear you don't care about them and take the issue lightly. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5c4cdcf81f1cd752663d81e5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote: > When people suggest tossing that all out for a minimally patched 4e, I think > some people rightfully feel a bit annoyed. That's a lot of baby that goes out with that bathwater. It's Davids decission what he includes as patches for the 4th edition but I would toss everything out of 9legacy which isn't part of the 4th edition or contributed by the team members at Bell Labs from their archives as enhancements. The reasoning is simple : p9f owns the rights for the final release and Nokia has made this release available under a MIT license. Every one who uses plan9 not only to toy around or his/her personal use but also as a system which he/she distributes like I do can't afford risks with code integrated from sources like 9front. There are some libraries taken from 9front derived from other open source projects like freetype (truetype) where copyright notices are absent and this isn't the only library where in code comments the sources are named but the original copyright notices are absent. plan9 as represented by p9f has a clear license all parts which are not MIT licensed are marked as such but code back ported from other forks like 9front contain code where I have doubts if those are really under an MIT license as you state in your documentation cause deriving from a different license or taking large amounts of code doesn't remove viral licenses like LGPL or GPL. It would be in the interest of plan9 and all who professionally use it in embedded systems or as a distributed operating system to keep suspicious code out of the 9legacy CD. If really necessary to provide such contributions or back ports I wouldn't place them in the system folders but as it was in the past in contrib folders for additional download. The risks to infect a clearly licensed system gifted by Nokia to all of us to make best use of it for free commercial private embedded ... solutions are to high and I would really prefer it when nothing from forks like 9front would take its way into the 9legacy CD ROM which is defined as : Plan 9 archives, reference releases of Plan 9. 9legacy, Plan 9 with many useful patches applied. Download page has an installation CD image including 386, amd64, and arm kernels and binaries; a bootable USB image for 386; a bootable SD card image for Raspberry Pi; and virtual disk images for QEMU and GCE. The 4th Edition distribution from Bell Labs: live CD/install CD/USB image, installation notes, browse the source, additional software I respect your fork 9front but I won't and can't use it. 9front isn't plan9 from my perspective. Plan 9 is the final release with patches for the files from sources I can be sure that those aren't taken from open source projects by copy and paste. The moment I and others who use plan9 for distribution or embed it on systems we have to be absolutely sure about the sources of the code. I can trust Bell Labs, Nokia, p9f but I won't trust some guys who toy around with their fork of plan9. The moment FSF or another organisation starts to suit me because they recognized that some guy at any forked system has copy pasted code from a viral licensed project I am the one who has to take the consequences. The first thing I am doing after downloading an iso from 9 legacy is to remove all files which were not part of the final plan9 release. The second thing I have always to do is removing all patches from the iso which came from sources I can't be sure if they really followed licensing rules. The third thing I have to do before distributing my fork of plan9 is to remove fonts ghostscript diff page and other parts of the system which would infect the distribution media to make sure the created system is not depending on viral licensed code. My fork isn't the only one which gets distributed. I'm sure there exist millions of devices with plan9 integrated without anyone noticing except for those who look into the documentation where the MIT licensed copyright is placed. If people from forks like 9front are talking about numbers of their users I always have to laugh. My fork is right now used by about 500 people per semester more users. And be assured this is an unimportant number. Not a single developer who uses plan9 for distributed systems, commercial products will dare to use a system like 9front as the sources. The reason is quite simple : You ignore copyrights as you please and distributed 9front under an MIT license long before Nokia as the owner of it decided to do so. You did that at a time when plan9 was placed under GPL. 9front is a fork your fork I respect your work. But all your commits and enhancements are absolutly useless for people who intend or use plan9 not only to play around with this system but make professional use of it. The first thing such people have to check
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Sorry for the double post ... try to use an older version of 9legacy cause after the integration of 9git in the latest CD a full system compile will stop. I don't know why such software which can't be considered a patch to the 4th edition became part of the src tree instead of putting it in a contrib folder. I personally would expect from 9legacy being 4th edition with only patches for files which were part of the official release and contributions made by original developers from bell (like compilers from personal archives aso). The first thing I do when testing a new release of 9legacy is to clean up the system from such enhancements. But thats another topic ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9df35c16c3c2bbeb846ea0cf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:17 AM, clinton wrote: > If I were completely naive to actually running plan9 but with many clues > about other operating systems and hardware, would it be better for me to > install 9legacy on some mildly obsolescent but still quite serviceable and > reliable hardware, or start with 9front on something more modern? If you are familar with linux and have a veteran computer with 8 GB I would start with 9vx and a 9legacy iso. This will simplify your first steps. Otherwise you will have to get used to so many different things at once that you will perhaps loose your confidence. The advantages taking this root are : i) No filesystem problems ii) No hardware problems iii) The ability to edit files in an editor of your choice iv) The ability to start all kinds of services from terminal, cpu server, file server aso on a single computer to try all those things out compile kernels write scripts try them out. ... After you get used to rio, acme, acid rc the next step I would suggest is build a network out of virtual machines with the filesystem of your choice. And even while doing so using one 9vx emulation will help you establish connections to all those virtual machines and allow you to make adjustments. After you have collected enough experience I would stay with 9legacy and ignore 9front. 9vx allows you to create boot media for old as well as new computers. You find everything necessary on the 9legacy CD (but also things which shouldn't have been back ported to 9legacy). If you need help walking this road don't hesitate to ask. I think a cold start with plan9 9legacy or 9front with so many different things will just take the fun away but using 9vx you will keep the fun and can immediatly start using plan 9 and 9vx is extremly fast. 9vx has some shortcomings like missing support for some devices but don't mind them cause you will end up installing plan9 on bare metal after you get used to it anyway. To sum up : 1. Step : Linux + 9vx + 9legacy (started for times) 2. Step : qemu + 9legacy (cpu, fileserver, terminal) + 9vx (for adjustments and as a rescue terminal) 3. Step : qemu + 9legacy (cpu, fileserver, terminal) + drawterm 4. Step : Bare metal as you like -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma839ab8f84a91bbe25ff8ed3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
Out of curiosity regarding your problem at hand Lucio : You could use 9vx on 9legacy to establish a connection directly. You said you have an optical drive on your old machine so why don't you just use the 9legacy CD ROM ? You could also put your drive in an external hd case and access it running 9legacy (qemu or bare metal) or 9vx. Creating a recovery stick of 9legacy to boot from an USB stick is also possible with 9vx or 9legacy with some tweaks simply integrated in a pre mk script is also no big deal. Did you solve your problem or do you need further details if so could you perhaps decide for on solution strategy ? If you just need to connect to a working plan9 I don't get the reason why you don't use 9legacy or 9vx instead of 9front. Perhaps I missed some reasoning. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M4c073a7a5f8954879334e1d2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] how to : create an p9f contrib folder
I read this website which had one of the old mail adresses : https://9p.io/wiki/plan9/how_to_contribute/index.html another one had the link to Geoff's mail at bell-labs as admin. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te9abe12004b50ce0-Mdd5d8a25e44c75fe292bbd19 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] how to : create an p9f contrib folder
Sorry the receiver was ge...@plan9.bell-labs.com this was the link provided by the 9p.io page it wasn't webmas...@9p.io -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te9abe12004b50ce0-M5a29d79bb7eb2d3f57d695de Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] how to : create an p9f contrib folder
I tried webmas...@9p.io -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te9abe12004b50ce0-M6a9cba504b1a6de5f69ff8d2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] how to : create an p9f contrib folder
On Friday, 26 January 2024, at 5:53 PM, David du Colombier wrote: > I don't think you can have a contrib account on p9f, but you can get a contrib account at 9p.io. Do you know who I have to contact for registration ? The mail I sent to p9f/9p.io couldn't be delivered. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te9abe12004b50ce0-M58eb38f51c28f56bf9926637 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] how to : create an p9f contrib folder
I would like to share runtime images of my plan9 fork and also some code changes which are not directly useful for plan9 but of interest for people using plan9 to provide kiosk systems. I tried to register at p9f and the mail I sent to the admin couldn't be delivered. I searched for info regarding this issue on 9fans but couldn't find any hints. How can I create an account and a folder on p9f in the contrib path ? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te9abe12004b50ce0-M785838c10fdc07f291d35a30 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]
First of all, I have my own fork of plan9 which was/is used by a few hundred users. My fork is based on 9legacy. And I'm really surprised to regularly see this discussion about a 'mainline' and the argumentation against 9front. Fact is : 9legacy provides patches and enhancements from 9front. I don't have a problem with those back ported code which is distributed under an MIT license. I don't use 9front or 9legacy directly but for some time now my own forked systems with different gui (desktop), editors, fontsystem, filesystem and a different coding style cause I prefer object oriented programming with C made possible with a preprocessor which translates to C. I'm not part of 9front neither of 9legacy. I'm following the 9front mailing lists for bug reports or announcements of code interesting enough to port to my system. Some improvements in 9front especially regarding drivers and support for hardware are worth the effort to run a diff and port changes to my system. 9front has a large user group and its natural that needs of such a large community improve hardware support. I use code imported by 9legacy for booting which simplified my fork and made booting on modern hardware possible. If 9legacy is the so called 'mainline' then 9legacy uses also back ported code from 9front. 9legacy is not 4e and it contains code enhancements from other forks of plan9 too. 4e is the last official release, 9legacy provides patches and enhancements back ported from forks of plan9. In my opinion 9fans is a meeting point not only for users of plan9 4e but also everyone who uses a fork of plan9. All forks share some code with varying amounts. I have my own fork and you wouldn't be able to tell by looking at the desktop or the boot screen that my fork is based on plan9, 9legacy, 9front as a user if this information wasn't placed due to the MIT license. My system is based on ideas code from plan9, 9legacy, 9fork and indirectly on code from other forks which were back ported by 9legacy this makes me part of the 9fans community like all those who are using plan9 directly or in the form of a port. The owner of plan9 4e - Nokia - relicensed plan9 under an MIT license. Using, forking, changing, distributing plan9 following this new license is something everyone can decide by him-/herself. No one needs any kind of approval from anybody as long as you fulfill the license clauses. My fork is based on plan9 - dot - 9front is based on plan9 - dot - 9legacy is based on 9legacy - dot and this is true for all forks which are related with plan9. By the way the original coders of plan9 also created a fork inferno. All forks are related with plan9. 9fans is a board where those interested in plan9 and its forks can meet an discuss. Whenever I need some information about problems existing in plan9 code I search for earlier posts on this mailing list, when I don't find relevant information I search the mailing list of 9front and others to find hints for solving the problem. I don't like this discussion about 'mainline' and forks on this list. plan9 is MIT licensed and can be used in its original form (if possible on modern hardware) or as a fork. Everyone can fork it and use it as he or she sees fit. I don't use 9front directly and sometimes discussions with people from 9front get irritating but this doesn't change the fact that they have a fork which is based on plan9 with a very good code quality that resembles the original form to an extent that it can be back ported with very small effort. Okay sometimes the effort gets bigger but thats the price you have to pay if you create your own fork and try to use code from another fork. I don't know any members of 9front by person never met any of them. But I don't like the way some on this board are discriminating people who have forked from plan9 or use forked versions. Who do you think you are ? Even the authors of plan9 forked plan9 or wrote user level software for systems to simulate plan9. If forking or changing the way to use plan9 is a crime and the evidence to justify to expel people from the plan9 or 9fans community who is still part of this community you envisioned (Don). After reading your messages you have also committed this crime by porting plan9 to systems not originally part of the 4e distro. You had to change enhance the code to make it run on new hardware not sharing it doesn't change the fact you made those changes so war you to expel from this message board ? The original authors changed code for their for inferno. They changed code between releases (9P --> 9P2000, ...), they changed even the gui between releases 8 1/2 ==> rio aso. Changing code is no crime as forking isn't thats the way software evolves. If you are a programmer and need changes you code the changes if you can't integrate those changes to the sources than you just created a fork. And as we all know plan9 4e was the last official release of
Re: [9fans] odd rwakeup qunlock behaviour in 9vx
Some time ago I wrote an email to p9f for registration of a user account in the contrib folder but that mail never got delivered. Otherwise I would regularly place a binare image for x86 for testing the effect of changes I made to the kernel and userland regarding performance. Regarding code samples : I'm using plan9 compilers as backends for my own C with Objects dialect which gets preprocessed and generates code understood by the plan9 compilers. My fork of plan9 isn't of general interest cause its goal is to provide a small (currently 4,8 MB) graphical terminal which connects to a closed area network server over tcp/ip for education purposes. I avoid using 9p where possible to improve the performance of the system which hasn't the goal to be a network operating system like plan9. I like the "everything is a file" model but implemented it in form of a block oriented memory file system using shared memory segments which leads to a great performance boost cause interprocess communication between processes on a single machine are realized in the form of file exchange without any form of translation to 9p and transfer over bytestreams which is surely necessary for a networking operating system like plan9 but not for an isolated machine which has only a proprietary tcp/ip protocol connection to a well defined server. For kernel files in /dev I wrote wrapper processes which transfer changes into the shared memory file system realm. In the first versions I used locks (especially lock and canlock) with polling in slave processes. For the next version I tried to avoid polling by using qlocks rsleep and rwake but while testing under 9vx, qemu and on bare metal the above mentioned problems appeared. When a process using Rendez and QLock structures in a shared memory segment called rwake more than once during its executing cycle first 9vx crashed than qemu crashed in an absurd way and also the bare metal version crashed. The reasoning behind this thread is only informing others about possible problems I encountered. I don't need a solution I already have a working workaround using simple locks. My code would be of no benefit for other plan9 users or developers but if there is interest for investigating the problem I can write a simplified example which reproduces this behavior. P.S. The shared memory is not attached with segattach but provided from rfork/exec which could be one reason behind this problem. rfork copies the parent segments into the list which can be accessed using proc/n/segment and using segments in this way is different from using segments by using segattach in many ways. Perhaps this is also the reason for the crashes. On Wednesday, 8 November 2023, at 10:08 PM, ori wrote: > A complete snippet to reproduce this may be useful. That said, I have code that uses qlock and rendez heavily with no sleeps, and have not had any issues on 9front. I also didn't have problems using qlock rendez without the combination of shared memory and rfork based shared segments. On Thursday, 9 November 2023, at 4:16 AM, Lucio De Re wrote: > I am sincerely hoping you intend to publish your efforts that certainly sound very promising. I intend shareing at least a binary version of my forked simple version after porting scintilla to my gui system cause right my system consists mainly of a viewer for a simplified markup which is used to present lecture notes, sound and animations (proprietary format). An editor is my minimal expectation towards myself before making such an image available for discussions on this mailing list. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Mfe4be6cb472537ea35f1d195 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] odd rwakeup qunlock behaviour in 9vx
Thanks for your reply. This behavior only appeared while using shared memory in form of segments. I already solved this problem by exchanging qlock, qunlock by lock (canlock). I also didn't have any problems while using other forms of memory constellations but while using shared memory segments this problem surfaced. I need this for my vgafb implementation which makes use of shared physical and normal shared memory segments. After testing on bare metal I also found out that qlock, qunlock, rsleep, rwake ... caused kernel crashes on bare metal while usual locks work without any problems. On 9vx I had to simulate vgafb with a implementation which provided my framebuffer with a shared segment to transfer changes to devdraw this made development easier but the moment I had concurrent access my software crashed. Debugging made clear the source of the crash was the described call combination while using shared memory segments. If there is interest for reproducing the exact circumstances I can write a small example app which involves different processes accessing the same shared memory segments which are inherited by the rfork methods. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-M62c35c1979d8c1e3f89621f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] odd rwakeup qunlock behaviour in 9vx
I have a function chan_send in which :
chan_send (...) {
qlock()
rwakeup(...)
qunlock()
}
If two such chan_send functions are called without a "task-switch" 9vx crashes.
A work around for this problem is to place a sleep(0) after qunlock to enforce
a task-switch
chan_send(...) {
qlock()
rwakeup(...)
qunlock()
sleep(0)
}
This behaviour isn't documented anywhere. I'll test it next on bare metal with
a real kernel to find out if this is only a 9vx problem.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T7a5bb3cde50a8a9a-Meba86a2cee63818883e31403
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9vx
I'm using it on a daily base for development and as a server plattform. 9vx is my terminal, while I use geany editor from linux as an editor. 9p filesystems can easily be started for data transfer with native 9legacy. The only feature I miss in 9vx is the lack of some plan9 devices in my case the #g (segment) device which I use for shared memory on 9legacy forks to create my graphical framebuffer and font infrastructure. But there is a simple workaround for this problem so I don't mind it too much. 9vx is extremly fast I can compile the kernel and userland in less than 2 minutes and the greatest advantage is the ability to use the underlying host filesystem directly from within linux. When I started kernel development with 9legacy after the licence changes I was looking for some way to exchange data between host and guest when someone pointed me to 9vx and afterwards it became my "thats it" solution. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M2906ba611422c3ebd4e2fa7e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Connecting root fileservers during boot
extended info to my last post in this thread ... the code fragments have to be placed in 9/boot/xxx.c while xxx.c is the name of your rootfile server file (paq.c embed.c ...). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T78ebc5723f2c00e1-M51fbf6121270ee09b7f99f87 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Connecting root fileservers during boot
While embedding root-filesystems to create a live-USB using paqfs I found some interesting behavior : Starting your user file server with *argp++ = "userfsrv"; *argp++ = "-S" ; *argp++ = "ufsrv" ; *argp++ = "-f" ; *argp++ = partition ; for(i=1; ihttps://9fans.topicbox.com/groups/9fans/T78ebc5723f2c00e1-Me9181c9334450bf348bf6ca1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] bug report : disk/fdisk
After creating an image file with : dd disk/mbr disk/fdisk disk/prep the resulting partition table in the mbr is buggy : the chs values in the mbr are incompatible with bios. bios uses the formula (c*H+h)*S+s-1 to calculate the lba values with H=256, S=63 while c (cylinder), h(head), s(sector) are the values from chs entries in the mbr partition table. disk/fdisk uses the same formula while setting H=64, S=32. If you write this image to real Hardware (HDD, USB-Sticks) some bios won't boot from such media especially if your boot drive has a size less than 8GB cause for media with sizes less than this size some bios'es use CHS addressing and some verify that sector id's from chs and lba are equal. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2298f52fc324cff9-Mb36b2ccec84dc4eb9d0a8c21 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] serious bug in ramfs and code based on it
The classic implementation of ramfs and many other user fileservers based on it have a serious bug regarding the 9p protocol : If you open a file for which you have Read/Execute Permission you are free to write to that file by sending Twrite requests. * * *rwrite doesn't check if the file was opened for read, write or execute. * A possible solution for this problem is enhancing the meaning of Fid.open from an indicator for open files to an indicator for open files and the mode they were opened : 0x80 ... file is open 0x40 ... opened for reading 0x20 ... opened for writing 0x10 ... opened for execution While ramfs is regared as a toy program with minimal permission checking many user file servers around are based on this example like all the tools in tapefs. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T08f89c41317a2e69-M990b45a03a13257b66e4e8bc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Problems with paqfs, kfs, bootdir
While testing existing fileservers I found some problems (9legacy) : 1) paqfs : Using a partion written by "mkpaqfs -u" as a root-fs with paqfs leads to "Bad Header Code" / "Bad Trailor Code". Are the current versions of mkpaqfs and paqfs incompatible ? 2) kfs/kfscmd The manual for kfscmd lists "noauth" as a command. The current implementation doesn't support "noauth". 3) bootdir size limit When adding files in bootdir (kernel) there exists a size limit. After reaching this limit the processor resets and the boot process restarts (bootloader : nboot/9bootfat, ...). I found this limit by adding raw files and testing for my configuration. It would be helpfull for others to mention the max size of the kernel image. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T14cd9f15ea5988dd-M853e46f4e13083cf2d529c97 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] A few questions about 9p
Thanks for your answer. On Saturday, 5 November 2022, at 3:09 PM, ori wrote: > The Tflush was successful: The Rflush does not indicate that a message was cancelled, tit indicates that the server is no longer processing the request. After your answer an read the manual pages a few times again and now I understand what to do : 1) All Tflush messages get a Rflush reply. If more than one Tflush arrives answering the last one means responding to all of them, like the manual states here : "A Rflush for any of the multiple Tflushes implies an answer for all previous ones. Therefore, should a server receive a request and then multiple flushes for that request, it need respond only to the last flush." 2)Even when oldtag doesn't represent an active message Tflush gets a Rflush response. 3) The only indicator for the client if his Tflush didn't interrupt (!!!) an active message cycle is (manual page) : If a response to the flushed request is received before the Rflush, the client must honor the response as if it had not been flushed, since the completed request may signify a state change in the server. For instance, Tcreate may have created a file and Twalk may have allocated a fid. If no response is received before the Rflush, the flushed transaction is considered to have been canceled, and should be treated as though it had never been sent. interpreted as : a) Server replies to oldtag before sending Rflush ==> indicates oldtag wasn't interrupted b) Server sends Rflush before responding to oldtag ==> indicates oldtag-message was interrupted 4) Its legal that a client sends Tflush messages with an invalid oldtag for which it can expect an Rflush as response never an Rerror (manual) : The server should answer the flush message immediately. If it recognizes oldtag as the tag of a pending transaction, it should abort any pending response and discard that tag. In either case, it should respond with an Rflush echoing the tag (not oldtag) of the Tflush message. A Tflush can never be responded to by an Rerror message. Now my interpretation of Tflush and Rflush quite changed : It seems that Tflush has at least two functions : (1) Interrupt a running message, while the probability to interrupt a running message is very small. (2) Polling the fileserver and guessing how it is implemented. A server with a simple sequential message processiong won't be able to respond to a Tflush by Rflush before responding to oldtag. A server which only replies to the n-th Tflush would be lagging and uses a message queue. Consequences for my implementation : 1) Its not an error if Tflush uses an invalid oldtag even using the ntag of Tflush as oldtag would be valid. 2) Every Tflush gets an Rflush directly or indirectly (response to the last in a series is enough) 3) Tflush can be used/abused to measure the fileserver performance. Send a message and flush it to measure the time needed to process it. Send n messages and measure the response time-differences, aso. 4) Tflush is not related with transactions but has to be taken as a rollback if sent for an oldtag that interrupts a running write operation. Thanks ori for your clear answers i got the right hints to check my understanding. And I had a misunderstanding regarding tflush till now so I needed to ask ;) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Ma697c45ddea03254971a41da Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] A few questions about 9p
Thank you for your clarifications Ori. From the perspective of kernel filesystems what you wrote made things clear. But one question remains regarding tflush and user fileservers : On Saturday, 5 November 2022, at 5:31 AM, ori wrote: > This situation is impossible -- you can always respond to a Tflush. Repeated > tflushes for the same tag may simply be coalesced into one response. tflush is also used to interrupt pending requests in user-file-systems. And there such a situation can happen where you can't respond to a Tflush. The server already processed the message for noldtag and sent its reply. Now you can't reply to a tflush with rflush cause that would mean the Tflush was successful and you can't answer with Rerror cause the rule says that Rerror is not allowed as a response to Tflush messages. Am I right regarding this situation or is this a misunderstanding. On Saturday, 5 November 2022, at 5:31 AM, ori wrote: > how would this work for file systems like kbdfs, /net, etc? your proposal > doesn't work for most of the file systems shipped with plan 9. You are right I only looked at the problems from the perspective of the user-fileservers I am developing right now. And so I tried to understand the possible impact of tflush for data-integrity. After your response I'll use this strategy in my user-fileservers : 1) Repond to Tflush right away with Rflush 2) Revert all changes to the file/directory ==> A full rollback 3) Invalidate the fid and reply with Rerror on the next message where this fid is used. 4) Make changes permanent only after a Tclunk for a valid fid. 5) Document this behavior. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M613a9a70317e111f7128e8d5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] A few questions about 9p
On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote: > I'd argue that this may be the most real-world-tested Tflush handler you'll > see. I have seen Tflush handlers that just return, having done nothing, and > it's possible that in many cases, that's good enough. But Chris's code is > VERY heavily tested with real workloads. I'm not surprised. Interrupting hardware access for a few kB and risking to damage the filesystem wouldn't be wise. On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote: > I also know, as I saw it many times, that the Plan 9 kernel Tflush could at > times get extremely confused. When we ported it to Akaros, we even saw cases > where Tflush would run out of control and exhaust the XID space, sending > flush after flush as fast as it could create them. > The rule : "Should multiple Tflushes be received for a pending request, they must be answered in order. A Rflush for any of the multiple Tflushes implies an answer for all previous ones. Therefore, should a server receive a request and then multiple flushes for that request, it need respond only to the last flush." and : "A Tflush can never be responded to by an Rerror message." should lead to a dead lock in this situation. Lets say the first Tflush arrived and got responded afterwards all the other Tflushes arrive and can't be responded so all ntags used by Tflush messages after the first can't be used by the client cause there are pending unanswered requests by the client. The server can never respond with an Rerror to a Tflush arriving out of order after the first Tflush got processed. 1) All ntags used for Tflush after the first are considered open. 2) A server can't even hint with an error for a Tflush with an inactive oldtag. Rerror with "error : noldtag invalid" would at least make the ntags reusable for the client. If the client code is conforming to the rules in man(5) Tflush messages can burn all possible ntag values (16 bit). If 9P2000 won't change at least some changes to the effects of Tflush and handling without breaking compatibility would be possible : 1) If a response to one of sent Tflush messages is made all Tflush messages regarding oldtag are responded not only preceeding ones, cause only one Rflush or only one response to the oldtag is allowed by the server. more important my suggestion : 2) Tflush also leads to a clunk of a fid. This lets the server decide if it will keep the changes or revert them. Those two changes would build a "mini-transaction" enviroment : Topen/Tcreate ==> starts a file transaction Tflush ==> interrupt file operation for fid associated with oldtag, clunk the fid with a rollback Tclunk ==> commit changes to the file Tversion ==> rollback all open changes not commited in the previous session. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Md0bfd4f48352cded476092f3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] A few questions about 9p
Thanks for your reply Ron. At least now I know that Tflush and Tversion in the middle of a running session can really be beasts and this wasn't only my imagination. I'm writing three filesystems for my applications needs. For the first the whole tflush, tversion (which is far more dangerous than tflush for a backend server) isn't important because this is a read-only bootfilesystem which replaces the boot infrastructure (9fat, nvram, kfs/fossil/paqfs/...) with a single partition (without the need to search for plan9.ini, boot, the kernel aso). The second filesystem is my fileserver/database front-end which resides on a host in the internet. And 9p is poison for this task (as defined in man 5 section). The current 9p protocol resembles in my opinion some kind of a transaction system while lacking the most important message "commit". Tversion starts a transaction (called session in the manual) and Tflush and Tversion are aquivalents to a "rollback" while there is no way to "commit" changes to the server. If the client loses his connection a real world backend would have to rollback all changes. Also Tflush, Tversion would make it necessary to store all changes temporarily while there the only message that represents a semi-commit would be Tclunk. The fileservers used on plan9 aren't affected by the lack of a session commit cause kfs as well as fossil are journaling filesystems (at least operatable in this way) but 9p enpowers the client while endangering the server. I rewrote fcall, lib9p to understand the 9p protocol and decided to write a front-end for my hosted fileserver(database+filesystem) based on a tcp protocol. While a plan9 client establishes a connection with sending Tversion I send a "begin" to the main server. After each Tclunk I send "commit" and "begin" and after a Tflush or Tversion I send a "rollback" and a "begin" to the Server for Tflush an immediate Rflush to the client. I'm not happy with this cause Tclunk as the marker for "commit" and "begin" isn't right but thats the way I did it now. If I would have the choice I would change 9p : Tversion <==> Tversion (handshake for protocol version and messagesize without rollback functionality) <==> Tbegin (Starting a transaction/session) Tflush <==> Trollback (only a renaming to make clear what is meant) Tcommit <==> (End the transaction and make the changes permanent) While at it I would also reduce the amount of information a client can aquire by a tstat or write with a twstat. I would also make ntags 64 bit or at least 32 bit. To summarize : I think the lack of a "commit" while starting a session with Tversion rolling it back with Tflush or Tversion has caused me some headache. Ron, thanks for replying. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M8716c512cdfc3a448b17a9ca Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] A few questions about 9p
I have read the manuals and also searched for this question here without finding an answer (perhaps I missed it) : 1) question about flush : Lets say there was a pending message with tag=1234 and the client of my server sent a flush message with a tag=1450. During the travel of the flush the server sent a response to the message tagged 1234 cause it finished. The manual states that the client has to forget about the flush message as if never sent. Does that mean that message tagged with 1450 which is now ignored by the server won't be replied (no error reply and no success reply cause if the server would reply with rflush the client would take this as if the flush succeeded due to the manual page). Can a client reuse a tag from an unanswered flush message immediatly (in the example tag 1450) 2) tversion A client sends tversion while in the middle of a running session. Is it right to abort/ignore/close/flush all possibly pending messages from the prior session ? The next question is regarding msize[4] in tversion. How should a server respond when msize suggested from the client is to small like msize-IOHDRSIZE< one min_stat_size ? Thanks in advance ;) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M9512c6004c50d17a43226b7f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: bluetooth
I'm interested if the results will be MIT or BSD2 licensed cause I want to share the results with 9front, 9legacy. I contacted you off list. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mbd443e03e4d49abe5fb798b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Perhaps someone can give me an advice ...
On Friday, 18 March 2022, at 9:07 PM, sirjofri wrote: > If someone does some work on native 9p stuff for android I'd really love some apk. I'm not an android dev, only did very few things on android programming-wise. After testing smb, ftpd and httpd approaches for my current problem I decided to use the ftpd and httpd solutions. The httpd solution combined with a uplaod html page which contains javascript using the file and xmlhttprequest api works on both android and ios without any needs for supplementary apps as long as scripting isn't restricted. The ftpd and smb approach also works but makes additional apps on the user phone necessary while most of those apps are freely available (also perhaps potentially dangerous for the users). While for my project there are no benefits doing this its possible to write a 9p fileserver in javascript only relying on the file and xmlhttprequest using html and the js file. It would temporarily make a 9p filesystem available on the plan9 side but I'm sure the connection will be closed unexpectedly by the browsers on the phone side so this will cause more problems than bring benefits. For my project using ftpd and httpd suffice cause my users can now transfer data directly to plan9 with tools available for android and ios. Instead of opening a new thread : I'm interested in low budget thin client solutions with plan9 as an intranet server which than connects to a web server for data exchange. Currently I have tested my approch on : Fujitsu S900, Lenovo M32, Igel M340. I didn't get my hands on a HP 610 or Fujitsu S920 perhaps someone already tried this and can share his experience. Also I prepare a list of low budget USB WLan Sticks which are supported by 9legacy and 9front enhancements. Currently I mastered support for sticks with Realtek RT 8188. I ordered about 20 different models with different chipsets for testing and adjusting the drivers. If somebody knows about other chipsets working with 9legacy or 9front just telling what works would be nice. While on wait I'm intending to port the freebsd bluetooth stack (netgraph) to plan9. I would be surprised if no one started such a project till now so if someone shares this goal I would be interested in a cooperative work. Thanks for replies ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Mab42e1f39d27c1ac16d3a01d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Perhaps someone can give me an advice ...
On Friday, 18 March 2022, at 12:19 AM, sirjofri wrote: > I personally use cifsd (on 9front) and on android totalcommander+smb extension. It works perfectly fine without any issues across all my android devices. I share some of the files with other users via tcp80 (behind tlssrv as https). I'm using totalcommander with ftp extension and didn't try smb. Thanks for the hint I'll give it a try. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-Md2fdb49288dd54d9d4a7e16e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Perhaps someone can give me an advice ...
On Thursday, 17 March 2022, at 7:53 PM, Skip Tavakkolian wrote: > For android, you could try to resurrect previous work by Tim Newsham based on Charles Forsyth's styx Java implementation: Thanks for the tip but I'm looking for a solution where I don't have to provide code for android or ios. I want to use built in protocols from these devices perhaps by implementing the counterpart on plan9. ftp and http are working already but if someone knows other working protocols I would try them ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M31bc71e711e44624e58006cc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Perhaps someone can give me an advice ...
1. My problem : I need a way to exchange images, videos and audio with smartphones, tabletts and usual computers which reside on the same wlan-router. 2. My solutions : All my solutions have in common that I used qr to generate a qr code which consists of the ip-adress and port on which to connect to plan9 running in qemu, 9vx or natively. 2.1. httpd I designed a web page which uses and XMLHttpRequest inside a script. This makes it possible to select files and transfer them to plan9. The solution works in chrome and firefox while safari sometimes causes problems due to the hard coded ip address. 2.2. ftpd I started a ftp server on plan9 which can be used by ftp clients from mobile devices which have a client app installed and this also works. 3. My question : Do you have any other suggestions how to solve this problem without making it necessary to write apps for the mobile device by only relying on standard protocols. Does anybody have any ideas or experience ? Would websockets be a better solution ? Thanks in advance. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tdd262593f40f8018-M4cd5fc72ff668b0a39316036 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] ftpd bugfix and enhancement
While using ftpd in 9vx and qemu I got response messages "Permission denied" in passive mode. This was caused in dialdata by dial(data,"20",0,0). While correcting this problem I also enhanced the options of ftpd to make it possible to use alternative ports instead of 20 for the data socket. ftpd got an optional parameter -P dataport which defaults to 20. The changes make it now possible to use ftpd from 9vx and qemu without port redirection. with a call like : aux/listen1 -vt tcp!*!13000 /bin/ip/ftpd -Aen namespace.ftp -P 13001 one can start a ftp server listening on port 13000 while using 13001 as its default data port. The diffs for ftpd.c and ipserv-manpage against 9legacy (latest version) are : DIFF FOR ftpd.c : 137,138d136 < char *dataport="20" ; < char dataadr[64] ; 177,178c175,176 < syslog(0, "ftp", "usage: %s [-aAde] [-n nsfile] [-P dataport]", argv0); < fprint(2, "usage: %s [-aAde] [-n nsfile] [-P dataport]\n", argv0); --- > syslog(0, "ftp", "usage: %s [-aAde] [-n nsfile]", argv0); > fprint(2, "usage: %s [-aAde] [-n nsfile]\n", argv0); 194,195c192 < int dataportid ; < --- 214,216d210 < case 'P' : < dataport = EARGF(usage()) ; < break ; 232,237d225 < /* prepare data port */ < dataportid=atol(dataport) ; < if (dataportid==0) < dataportid=20 ; < snprint(dataadr,64,"tcp!*!%d",dataportid) ; < 1697c1685 < fd = dial(data, dataadr, 0, 0); --- > fd = dial(data, "20", 0, 0); 1710d1697 < Diff for man/8/ipserv 18,19d17 < .RB [ -P < .IR dataport ] 170,172d167 < .TP < .B P < the port used for the data socket (default 20) 181,188d175 < .PP < .SH EXAMPLE < .PP < Start ftpd with control port 13000 and data port 13001 while using prepared namespace /usr/glenda/ftp/namespace.ftp for anonymous access. < .PP < .EX < aux/listen1 -vt tcp!*!13000 /bin/ip/ftpd -Aen /usr/glenda/ftp/namespace.ftp -P 13001 < .EE FURTHER COMMENT : ftpd makes data exchange between UNIX hosts and plan9 guests while using qemu very simple. ftpd can be started from 9vx in usermode when using ports other than 21(20). Some ftp clients ask for utf8 opt and this is ignored by ftpd my next patch will adress this problem. Comments are welcome. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5cbecf1a4fb8cf5e-Mcd4d16fb44d1c44c68272702 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Friday, 4 February 2022, at 4:30 PM, Kent R. Spillner wrote: > In your experience do students appreciate being told what's best for them? ;) My platform isn't one for teaching programing its for teaching other subjects like math, electronics, statics and so on. It's neither my goal nor the intention of such a project to teach the students how to realize such a project. The suggestion that I would include the code so that someone could learn from it is unrealistic. If one of those students get interested in the way I did the whole thing they find the links for the projects I used as a basement. Neither operating system development nor programming in C for plan9 are subjects of my platform and so there is no benefit for my students having the sources. If someone gets interested he/she can use the links for the used open source projects and become fans of whatever they like. Perhaps some will get motivated by using such a system to invest the necessary time and effort. I don't hide what I used so they can become enthusiasts if they want to. But this platform doesn't need accompanied sources nor will the students have direct access to a shell or the tools everything is hidden behind a simple kiosk app which has no other goal beside being the "envelop" for the real information meant to be taught. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Maa0df4bb413196b925180ef0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Wednesday, 2 February 2022, at 7:22 PM, ron minnich wrote: > This one statement: "Berkeley stopped their distribution of BSD systems right after they were forced to remove the toolchain." is completely wrong. I just asked the people who were there, on TUHS, and they confirmed my memory: DARPA funding for BSD support ended in 1995, and that was probably the biggest factor in ending the UCB activities in BSD. I think it's important to verify claims with primary sources. Many of those people are still alive. Thank you for the clearance. Looking from a distance I misinterpreted the real reasons and I never met the primary sources in person. That was my interpretation and as it seems it was wrong. Thank you for your effort to make things more clear. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M959b3645d30c70355fd751cb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Sunday, 30 January 2022, at 10:00 PM, ron minnich wrote: > That happened about 10 years earlier. The effort I am talking about with jmk was 2013; the dustup with Theo was circa 2003: Thanks for sharing those facts. On Saturday, 29 January 2022, at 3:26 PM, David Leimbach wrote: > I haven’t ever heard the compiler tool chain was a big reason, but I’d be > interested to hear your perspective here. GCC can produce code of any license. Until the BSD systems switched to llvm even the most basic installment was depending on gcc. The integrated system compiler was gpl'ed and on a unix system where the c compiler was the most important tool to achive portability this did never seem right. On Tuesday, 1 February 2022, at 3:12 PM, Dan Cross wrote: > This isn't really on-topic for 9fans, but I find this hard to believe. Linux > used the exact same compiler suite, and became wildly successful while the > BSD distributions mostly stagnated; certainly, the BSDs never grew at the > rate or reached the levels of popularity that Linux has attained: it wasn't > the license on the toolchain. Berkeley stopped their distribution of BSD systems right after they were forced to remove the toolchain. The last releases were 4.3 and 4.4 lite. Then the project got forked. It led to a stop in development. I personally believe that this was the main reason behind the BSD's to lose their charm. If you read about the reasoning why as an example Minix or even plan9 got their own toolchains I think you can read between the lines that the lack or the existence of a toolchain with the right license is far more important than many believe. Of course this is only my personal opinion and probably I'm misinterpreting things. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M3273bb43a0299b4d186eef36 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Sunday, 30 January 2022, at 8:55 AM, tlaronde wrote: > The lacking piece is the end: converting DVI to something else than PS and extending DVI to include drawing primitives so that there is a "MetaPost" generating DVI (Metadraw). The other points are already addressed. Perhaps xdvi is a good start point to understand how to convert dvi to raw images. dvi isn't a ready to display format you have to prepare the missing glyphs (fonts). Knuth has provided a converter to make dvi files human readable and you task is to interpret this output. If you take a viewer as a start point you could store the fineshed rendering in a file instead of saving that. Like ps dvi is also a virtual machine code but much simpler. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Ma1bb971f183183e809d2ee6d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Sunday, 30 January 2022, at 2:45 AM, ron minnich wrote: > The late jmk and I labored over a period of many months in 2013 to get Plan 9 out under a BSD license. In the end, the copyright holder at that time required that we distribute it, via UC Berkeley, under the GPL. No choice. It was that or nothing. Those negotiations involved many people, and it almost did not happen at all. As far as I recall OpenBSD (Theo dR) was interested in BSD licensed compilers at that time and that didn't happen. On Sunday, 30 January 2022, at 2:45 AM, ron minnich wrote: > The p9f process was not a relicensing, it was a transfer of ownership of the code. One condition of the transfer, was that the GPL was explicitly named as a license we should not use. All agreed that the MIT license was a good one. Thanks for this choice and your efforts during those negotiations. I only read about the expectations from BSD projects which were hoping to get an alternative Compiler for GCC. But that didn't happen at that time. Thank you for clarifying things sorry if I made wrong assumptions. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M7727dcecedf37178853eb7de Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
What I meant was that there is no sense in sharing the code for a special purpose kiosk app. For people who are interested search for gpl infringement tv boxes You will find many examples of companies who took gpl too lightly and got sued by FSF. The more users a product has which used GPL without making the code available the higher the risk gets that they get sued. FSF isn't as weak as many think they are. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mecdec31b77bfe5c013b8342d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Sunday, 30 January 2022, at 12:14 AM, sirjofri wrote: > Maybe I misunderstood something about licensing stuff but, can't you just distribute the working build product (binaries etc, without source) to the TV set (or kiosk) and keep the source in a completely separate open space, under some open source license? I mean, does open source (gpl, mit) mean, you have to distribute the source in the same device? That wasn't about licensing rules but part of the answer to hiro. You misunderstood the purpose of this sample or perhaps I didn't make it clear (sorry for that) As a side node if you search for GPL infringements you will find some examples of large scale companies who used embedded linux without sharing their code in such devices. On Sunday, 30 January 2022, at 12:14 AM, sirjofri wrote: > At least that would have issues with any linux distribution I know, where you usually just download prebuilt binaries and have to download the source separately. What you said is right you can make binary distributions but have to provide the sources. The rules are described in detail here : https://www.gnu.org/licenses/gpl-faq.html -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mce36a50cdc0abc563e2d2591 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 11:14 PM, Bakul Shah wrote: > Note that djvu would compress things very nicely. A full page 300dpi magazine color page that may be 25MB uncompressed will compress down to 40K-80K or so and be very legible, much more so compared a similar sized jpeg compressed image. Thanks for your hint. I'm using djvu format for scanned book pages for my private use. The algorithm isn't easy to reimplement cause it uses pattern matching in an extensive way. You get the best results for scanned material where as an example letters are matched quite often. It has superb compression ratios but is slow regarding decompression or rendering. Regarding handwritten scans the best method I experienced is edge detection filtering and color indexing to create a ppm image. Compression leads than to smaller sizes than by using jpeg. Decompression is faster and when you combine two lines to single one (subpixeling) you get smooth and clean images. For printed sources djvu produces far smaller results. Thank you for this hint. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M9f60f8b5ffc2c3bb7b2c02d9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 10:42 PM, hiro wrote: > Proof of concepts have value, too :) It's quite funny what kind of stuff somebody might dig up in 2 decades and learn something unexpected from it, happens here all the time. I'm not saying I will personally have a need for the system, but I'd like to spread this culture and make sure people share all they can. As long as it compiles... Lets take a tv set as an example for a kiosk application thats not far away. What benefit does the user of a tv have if I put the sourcecode of the tv set into the mounted flash device ? Sure everybody could benefit from reading the way I programed embedded circuit but aren't there better ways to share this information ? As you remember from the other thread where we talked I am willing and interested to share code of interest for plan9 or derivates of it but therefore I started that discussion. I will use plan9 as a kiosk OS or as a desktop OS and if there is interest in my experiences and if there are others who intend to use this OS also in this way I want to share code, documentation and give support. I'm a software developer since 1986 I wrote a book about Visual C++ and contributed primarily to BSD projects. I don't know long you are part of open sourced software but my first open source software projects date from 1986 published in the german C64 magazines. Prior to the MIT licensing of plan9 I didn't use it for distributed software. My preference was OpenBSD and FreeBSD depending on the project. I don't contribute to GPL projects because that doesn't fit my opinion of open source. There are at least 5 mio people on the planet who make a living directly as developers and ten times as much making a living out of developed software products. The free beer philosophy sounds nice but the IT sector is the most important economical sector today. We are not living in paradise and people have to earn money by their work. You never asked me to share code I offered that on my own and I started another thread to make it in the right way. I respect the pioneers who developed plan9 at Bell and I don't want to break anything in plan9. I am using plan9 now for my projects ! And I will use it more frequently in the future ! Projects I'm doing for a living will be closed source ! In my spare time I want to support this great project and share code which gives others a good basement to also use plan9 in other ways even commercial ways to make a living out of it but which will also give idealists the opportunity to write code for a better world. I did that in the past and I'm doing it today. BSD and MIT licenses support this and the reason why I decided to give plan9 a try in a real project was the changed license. I don't disagree to what you said cause I support open source projects and I'm making use of them. But development is not only a hobby of mine but also the way I earn my living. I don't know how things are for you but when I go shopping and am asked for the payment no one will say you don't have to pay because you are sharing everything you can for free. And be assured I'm not ashamed of the fact that I am making a living out of development education or development of software. I want to share some of my work but not all. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M06aba0b70dbfbe6782340dc3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 10:18 PM, Steve Simon wrote: > Someone doesn’t like GPLs, can we not just accept this and not tell them they > are wrong. And if they wish not to release the source for their work, again that is their decision. Thanks for your support. I mean it. I don't get the argumentations here. Everyone was happy that plan9 was relicensed as MIT last year. If no one is allowed to make closed source distributions of plan9 based systems than why were all unhappy with the prior licenses. Years ago plan9 was licensed as GPL. 9front kept licensing with MIT. If you expect everybody to make their products and systems fully open sourced than you should have sticked with the GPL license. I admired the determination of 9front taking this step for years. Now I'm really surprised about some remarks in this thread. BSD or MIT licensed software encourages the use of such software in closed source products. GPL restricts this. I'm also willing to support those projects with code I thing will be of value for others and giving them also the right to use this code open sourced or closed source as they prefer and allowed by applying the mit licence for my parts. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M300d0dce4e0019b8b17fae4a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 9:44 PM, hiro wrote: > if the odd one out of the students learns plan9 you think that's not worth their while? then why do you use plan9 yourself? i would have loved to have a teacher in uni that uses plan9. I don't can't and won't hide the fact that my virtual machine image is based upon plan9, 9front. It's based upon so every student will find references links to associated projects. Therefore I asked for your prefered form of acknowledgement. On Saturday, 29 January 2022, at 9:44 PM, hiro wrote: > what makes you think everything will work and your students are happy with the system? In the last decade students using the freebsd version very happy with it and I hope students from the wintersemester will also be happy. This platform is meant to support them learning their examination stuff and the feedback is not bad. There will always be roam for improvements, there will always be bugs. All I can do is do my best. On Saturday, 29 January 2022, at 9:48 PM, hiro wrote: > yes, it's very dangerous in terms of licensing. i suggest you rewrite ghostscript as gs/pdf reading ability is very important for most users (even for our own docs). I don't need this cause I am representing drawing data as svg or in a format similar to emf (enhanced metafile). Images are represented till now in zipped ppm format. Fonts are represented in ttf. And I support the dvi format produced by tex and metafont. pdf and ps make the use of fonts necessary which have licensing issues. On Saturday, 29 January 2022, at 9:48 PM, hiro wrote: > looking forward to your code submissions. I am at it. As you remember from the other thread there is no agreement about adding framebuffer support to plan9. This will show a simple application which doesn't use devdraw, memdraw, memlayer and can't coexist with them. If their are no agreements about how and where to support a framebuffer interface its not worth the effort to implement it in a compatible way. This proof of concept version will only give a taste about what would be possible. (Expect some kind of animation without text rendering - which is not difficult but needs a clear interface definition). Of course I would prefer to share those parts with the main distros/forks of plan9 the more they are used the better they get and the more possible bugs will be discovered. But if you expect a desktop alternative to rio with a theming window manager than an agreement is necessary to not waste time for things never meant to be part of plan9. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M586a4373747116cfeee6fdbb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 7:58 PM, cinap_lenrek wrote: > on the other hand, calling the ghostscript interpreter as a external program, i dont think that would force your program kiosk to be gpl licensed (for example page(1) would be in the same situation... it calls all kinds of external image converters, including ghostscript). https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins this plugin concept is the reason. The moment you include a gpl program and use it for two sided communications and you depend on this to fulfill your task than you get into trouble. Otherwise any gpl licensed program could be used this way. You write a few dozen lines forc, exec and pipe. Plugins form a single application. The border line is where you depend on a single gpl licensed program. There exists one program and that is gpl ed without using this program yours won't work than your program is called a single combined work. Otherwise their are dozens of programs and you don't depend on a gpl'ed software but you offer an interface for communicating with it also that doesn't form a single combined work. You don't depend on that. Regarding ghostscript. As clearly stated in release 3 of plan9 Bell labs had a distribution license from aladdin. But we don't know if this license was carried over to p9f. But at some point in time the licenced version of ghostscript was switched to a general aladdin licensed version accompanied by the regular license. Aladdin is similar to gpl regarding this plugin tematics. I personally would say using page for displaying pdf or ps is dangerous and makes a distribution depending on this feature highly dangerous for developers. My question was not only connected with my kiosk application but a general license question. For this project I prefer a closed source distribution as I would for embedded systems. In other projects I wouldn't mind making parts of the code available other parts not. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M7498b48e28e05e603b1c6c46 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 7:12 PM, Grant Defayette wrote: > Honestly I really don't see the issue with an 800mb network image. These > kiosk machines and network should be able to handle that with no issues and > it should fit on a disk easily. What constraint are you trying to solve? You > want to switch from an easy to maintain by any Unix expert with fully > available source to an obscure system that very few people use today and > might have issues with redistribution of sources and fonts etc just to > satisfy a constraint that doesn't exist. This is the kind of thing that would > only fly at a university where they allow people to make strange decisions > that solve problems that don't really exist. I wrote earlier that the first project I'm using plan9 now is this kiosk application and this was already realized with FreeBSD. The purpose of such a step was also to test how difficult would it be to realize a project with plan9. I am also developing embedded software for bare metal and this test made clear plan9 is the best choice for this kind of projects. Its small the underlying abstractions fulfilled their purpose and you get a full fledged OS useful for many tasks if you are brave enough to change some parts which won't fit your demands. We are writing on 9fans so everyone present here made the choice to at least test a system which you call "obscure system that very few people use today". plan9 was a research project to start with and its not obscure at all. plan9, 9front are available running on different hardware even in raspberry pi (4 B) out of the box. I don't think that its a strange decision to use an existing working platform to realize projects. The code quality is good as could be expected from people who created unix. As a side note when the first ten people used unix and others also decided to switch than all of them made this so called "strange decision" and today unix used everywhere. I didn't have any remarkable problems substituting the fonts, and I won't have any problems substituting the remaining parts which are not MIT licensed if needed. You can only decide to use a project like this as a basement if you realize a few projects using it. As the Bell people remarked on the plan9 papers plan9 was used as an embedded system in commercial projects. You think Bell would have distributed this system and products based on it without verifying its reliability and quality ? The people involved in the development of plan9 are creators of unix the most important compilers the best known tools and they used this in their daily work. If you look in one of the current threads regarding a three buttoned mouse you will see that the first who answered was Rob Pike who perhaps still uses acme and some form of plan9. I don't have any doubts about the software quality of plan9 so be assured that I will use this project without doubts and this decision is definitely not obscure. Believe it or not if plan9 had an MIT license from the beginning you can be sure that the market share of plan9 would have be at least on the level of BSD systems. Its simpler its smaller and the concepts are good. There would have been forks cause of different tastes for the GUI but that is something normal. A kiosk app as a test case for the decision if the chosen OS can be handled or causes unpredictable problems is the way I have chosen for myself. After a while I will learn about problems arising from this decision without harming anybody. Not the users and not me as the maintainer. This will improve my experience. Regarding the size of the image. This is a service I'm providing from a dedicated Server on a commercial host. The most students today are using apple mac books they can't and won't install any operating system on those machines and I'm not willing to support x machine architectures for a students course. On my dedicated server there was placed a torrent file so I could handle the bandwidth problem in a acceptable way. At the beginning of each semester there are hundreds of downloads for this ISO. Estimated 60% of the students have to use virtual machines to start this ISO. Reducing the size of the ISO and the necessary RAM drive size where the ISO gets loaded to increases the performance. If a student has a 4 GB laptop he can afford approximately 1 to 2 GB of system memory for use with the virtual machine. Besides the ISO you have to allocate process memory so the size impacts performance regarding my experience. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M5bae393595a57178e96c5959 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 5:56 PM, Bakul Shah wrote: > Also note that plan9 c compilers are likely no faster than tcc. And there will > be other challenges. My kiosk application using plan 9 and its compilers is already working. There were no problems changing from llvm to plan9 compilers. The speek difference between plan9 compiled code and gcc, llvm compiled code is irrelevant. I use compilers for many different tasks to avoid scripting at all. Everything gets expressed as C files which get automatically generated, translated and are called as child processes while using pipes. Some of those C files are for the generation of plot and graph data (2D, 3D). This data than gets rendered into image files which than are displayed. The system works similar to gnuplot, asymptote aso with the difference that no external interpreter is used. This works simpler and faster using plan9 as using freebsd and llvm. The plan9 compilers are ideal for jit tasks. On Saturday, 29 January 2022, at 5:56 PM, Bakul Shah wrote: > Not to dissuade you from switching to plan9 but just pointing out > there are ways to reduce the image size while staying with FreeBSD. Don't worry I already realized my kiosk app using plan9 and wanted to make sure of their are licensing problems I didn't know about. I only use the libraries so the problems regarding commands aren't important for me. The second reason why I asked here is cause if there are prefered ways of acknowledgement I would include those. After this thread I will place something like "This software is based in parts on plan9, legacy9 and 9front. Those are licensed under MiT . For those who are interested in those projects " As a sign of my gratitude and after the results of my other thread and the lack of interest for a framebuffer device I intend to write a pdf and contribute reduced versions of devdraw, memlayer, memdraw which can be used for creation of such framebuffer based distributions which don't need the plan9 gui. This will be licenced under the MIT. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M7b9ae9bc73a39379d01d7fba Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Saturday, 29 January 2022, at 2:24 PM, hiro wrote: > i don't buy the argument that source code would be too big. for just one subject in school i had to download many gigabytes of quartus, over a decade ago. our source is nowhere near that big. A kiosk application for educational purposes in subjects not involving programming consists of tools for viewing texts, animations, images, a calculator a plotter and an interface do upload pictures taken from your handwritten assignments. There is also a chat platform for group chats and individual talking. The whole plattform uses TCP/IP as its only communication protocol avoiding existing RFC standards. The GUI is similar to a web site but looks more like a desktop with windows where all tools like calculator, chat clients, upload tools are represented by floating windows. Nothing more and nothing less. The purpose of this application is not teaching the students how to realize such a platform but the subjects they need to pass their exams at university. There is no benefit for the students to learn how to realize such a platform and thats also not the goal of this project. My Freebsd version has now 800 MB. A great amount of this size is caused by hand written sample solution scans for past exams provided as 300dpi images (png or ppm). Most of my notes are handwritten cause this way to provide solutions for exam questions is faster and simpler. Some of the teachings are provided as ogg vorbis files. The system part regarding Freebsd and X11 can be reduced by using plan9 dramatically. My own software has a few MB. In the plan9 distribution I will use a new image format based on horizontal scanlines using 256 colors. This has an acceptable quality is faster to render and the size of the image files will shrink to about 25%. 800 MB aren't only the sources they include the base course material. The application has to make this material visible, usable and allow students to connect to deliver their assignments ask questions get back hand written notes and to exchange information with others using this closed network. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M16ce34d043025f8cd079636e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Friday, 28 January 2022, at 10:59 PM, hiro wrote: > why should it be closed source? you're gonna seriously put the effort to remove all the traces of source files? This kiosk app is meant for students in math, electrotechnics, mechanics ... its a closed area network where only registered students can connect. This plattform is only meant for exchange of data and informations. The app is distributed as an iso to be run from bare hardware or qemu (virtual box). The current version is running based on FreeBSD and has a size caused by X11 necessity and accompanying programs of 800 MB. I'm trying to reduce the size and increasing the performance by using plan9. My plattform generates form many simulation tasks, symbolic calculations, plotting, ... intermediate C code and translates this to programs which are called as child processes and generate their output for rendering. LLVM is needed two times in the FreeBSD installation once for X11 and once as a system compiler. By using plan9 I can reduce the size of this kiosk application to estimated 300 MB. I gave plan9 a try a few years ago and was fascinated but the licence wasn't attractive at that time. But now it's ideal for such tasks. Some sources are part of this installment inside a loop file those are provided internally with a ramfs so in time compilation gets possible. The moment I include GPL licensed code into this ramfs this would infect my own licence. My plattform is BSD 2 claused the students can distribute it freely but the mechanics for connecting to the closed area network are hidden. The MIT licence, zlib, Ogg Vorbis license are compatible with BSD 2 license and require proper acknowlegdement but GPL can't be used in such a manner. Plan9 with its new license is optimal for such applications. I think that plan9 would have been more wide spread if this new license would have been applied from the beginning. And I believe that the reason why NetBSD, OpenBSD, FreeBSD are not as wide spread as Linux was the lack of a compiler suite conforming to the BSD license. Some time ago the BSD project asked for a license change for plan9 to integrate the C compiler which didn't happen at that time. But I'm sure that in the near future their will be some BSD forks which will take more ideas and tools from Plan9 (especially the compiler suite). Plan9 has more advantages besides those - nearly direct access to the hardware and a simplified way to enhancements due to its namespaces and 9fs. I'm using BSD systems since 1991 and I think its important to follow a strict licensing scheme otherwise many years later as it happened in NetBSD, FreeBSD and OpenBSD you start to search for alternative implementations cause at some point your code is not accompanied by incompatible licensed code but is depending on those so it is infected. If you decide to distribute a system with a non infecting open source license than its important to do this in a consistent form. The more time passes the more you depend on parts and the less gets the chance to exchange those parts. I am consequently avoiding infecting licenses in my projects and my distributions for decades now and those parts of plan9 (9front) which are not conforming are not a big deal to throw away. diff, patch are available in conforming licensed versions. I prefer ogg vorbis to mp3 due to its patent problems in the past. There are dozens of truetype fonts with better quality and distributable. The only problematic part not only to plan9 but also all BSD systems is ghostscript but I have an existing translater from postscript to svg and a closed source svg library for rendering for other projects where I would perhaps need page and the dependency to ghostscript. No need for lzip and xen ... The reason why this reply was this long is simple : My experience from the past and my involvements in BSD projects tought me that many open source projects try to take large steps in short time and most often they borrow code or libraries from projects not conforming with their chosen license. Legal questions are taken very lightly for a few years but than at some point in time those legal questions surface. The reason why linux took over was this simple - BSD 4.3 lost its compilers. There are people (I am one of them) who also have to write commercial projects for a living. I'm developing embedded software for electronic circuits and plan9 is now a real alternative for me cause of its new license. I can decide for each project if I want to make it open source or not. And by consequently avoiding infecting licenses I can use the same code base for open source as well as closed source projects. Why do you think p9f asked for a relicensing of plan9 while it was already gpl licensed a few years ago ? Both are redistributable but the MIT version is also usable for closed source commercial projects while the GPL version is not. Does this matter ? Yes of course it
Re: [9fans] suggestion : new service targets for plan9
A well established example for direct rendered frame support is the SHM extension of X11. There you can create a shared memory in your application and render directly into this. Afterwards you switch buffers without any transfer of image data. The image is directly rendered on the screen if the application and the display rest on the same computer. In X11 this results in a great performance gain cause you don't have to invoke X11 for each drawing primitive and you don't have to transfer the image data when the image is ready. libSDL uses a similar approach. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Me6991ab04cfbfa8bef2b4f2c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] suggestion : new service targets for plan9
On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > I didn't deep-dive yet into the internals of it, but isn't it that when > combining the images at the end, that transfer of the initial images with > lots of data basically happens only once? It seems to me devdraw can be quite > performant on certain use cases. (UIs with basic shapes) Thats true. devdraw prepares its images using memdraw and memlayer. After combining those images we get the results on the display. The moment you do rendering inside your application you have to transfer images using loadimage and flashimage. There is no message inside devdraw which makes it possible to use images from a client process without copying them into the memlayer infrastructure. On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote: > Also I wonder what kind of functions it should be providing. This intermediate or alternative layer should only add putimage switchbuffers supported by shared memory segments. At least there should be two buffers one foreground and one background buffer directly writeable by the client. One simple way to realize this would be enhancing devdraw with one single protocol which would render a client side image from shared memory (segments). You can quite now create memimages but if you realize the rendering you have to use loadimage and flushimage each time your images change. devdraw is not slow but it can be made faster with only one extra protocol which is missing. Enhancing devdraw this way would also solve the problem but not touching devdraw and offering an intermediate level between the graphics driver and devdraw wouldn't break anything. In the end devdraw also transfers its image to the videocard one way or the other. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mbe750adf3a20ec4a7f7c7b5d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] suggestion : new service targets for plan9
On Friday, 28 January 2022, at 10:55 AM, Frank D. Engel, Jr. wrote: > As far as I can tell this would require practically zero core changes to the system as it is built entirely on existing primitives already offered. What you are suggesting is a higher level filesystem and libdraw combined with the panel library is implemented in a comparable way. This results in decrease of performance. Because the renderer has to read all the files for all visible regions on the screen and combine them for the display image. memdraw and memlayer which are used by devdraw are doing a similar job they combine image memory layers to form the resulting display image. What I suggest is a lower level interface to use the framebuffer directly and I think devdraw (memdraw, memlayer) is too high level and rio oriented. If you use devdraw as a framebuffer than the only functions you need from devdraw are initdraw, loadimage and flushimage which internally use memdraw and memlayer in a way that decreases performance. Also the transfer of images in this way is expensive (regarding time) a screen image is at least copied two times. So by defining a lower level we could improve the performance of rendering by a factor of two. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Meea8f954e2d142447d743e3f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
On Friday, 28 January 2022, at 4:23 AM, Kurt H Maier wrote: > None of these prohibit redistribution. Feel free to delete them from your copy. I'm intending to distribute a closed source binary release as a kiosk application which will be used as a graphical terminal for students. So anything containing GPL code can't be part of the base installment. Users can decide to download and install binaries on their computer but the moment I distribute a GPL application as an integral part of my system where some of the binaries depend on their existence without alternatives my code and binaries get infected by GPL. I already deleted ghostscript and all fonts from 9front to avoid legal problems. Xen, mp3dec, lzip weren't used by my app the only surprises were diff and patch which I can substitute by not GPL'ed versions. You are right if I would distribute my kiosk software in binary and source form like all plan9 distributions do. Then I would have fulfilled the necessities of GPL regarding redistribution. But the problem of "work based upon", "word depends on" would perhaps remain for some of the tools used by plan9. In common you are right but not when someone makes a binary distribution ... Thanks -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mf8a2f7c56fff6ebad6c88447 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] suggestion : new service targets for plan9
On Friday, 28 January 2022, at 8:53 AM, vic.thacker wrote: > Hmm. Have you considered using Inferno? I gave it a try long ago but I don't want to use it. The reason is the involvement of limbo. I prefer system code to be written in a language that I'm using now for decades and where I can change even the compiler for my needs. I wouldn't use the first releases of plan9 either due to the same reason (alef). Another reason why I prefer legacy9 or 9front is the evolving codebase. Both projects are active and the more people share the code the more bugs get explored. The ideas behind inferno are compatible to mine but I prefer an active project as the shared basement for enhancements of a system. But thanks for this hint, cause my suggestions are already integrated in inferno and if I would only need an existing solution using inferno would make sense. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mc26a105eafd97f19f62fbcc0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] suggestion : new service targets for plan9
On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> It'd probably make sense to generalize: 'service=foo'
in plan9.ini could run /bin/^$foo^rc.
This is an excerpt for one experimental gdi from profile
...
ramfs
font = /lib/font/bit/lucida/unicode.10.font
upas/fs
fn cd { builtin cd $* && awd } # for acme
service=kiosk
case kiosk
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' ' ')
fn term%{ $* }
# cat /sys/lib/kbmap/de > /dev/kbmap
exec /usr/glenda/proj/gdi/gdi
# exec rio -f /lib/font/bit/lucida/unicode.10.font
case terminal
plumber
echo -n accelerated > '#m/mousectl'
echo -n 'res 3' > '#m/mousectl'
prompt=('term% ' ' ')
fn term%{ $* }
exec rio -f /lib/font/bit/lucida/unicode.10.font
# exec /usr/glenda/proj/gdi/gdi
...
I defined kiosk as a service target inside profile and by editing profile
before starting I can switch between the new window system and rio both can run
inside each other. By defining well known targets like kiosk or desktop aso the
compilation would get easier and due to the existing environment variable the
running main window system would be known to client apps (even if not
necessary)On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> Why would another layer be help?
Libmemdraw is not very fast, and profiling+optimization
will be needed to solve that, but I'm not sure what an
additional layer is supposed to do there.
The extra layer would make sharing of the optimized framebuffer device usable
for both window managers directly using this fbdev and also for devdraw
(memlayer, memdraw). In last instance devdraw does also render to the graphics
memory so this layer would be shared by both. This extra layer would make sure
that only one application has direct access to the framebuffer while the other
gets multiplexed. I did the multiplexing in my window manager for rio so its
possible to run my window manager inside rio and vice versa. The alternative
would be a parallel fbdev with the risk that both devdraw as well as this dev
driver try to write concurently to the video memory. The changes to memlayer
memdraw devdraw would be minimalistic but are not really necessary. Those
changes would make both window systems benefit by a shared code base and
improvements in this code base while totally transparent for any application
running on the system.
On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> Sure. It fits -- same place as kbdfs -- but someone
needs to come up with the event encoding, write the
'touchfs', and implement the readers that toss events
down channels.
Nothing insurmountable, just needs someone who cares
about it to roll up their sleeves and write code.
if(initdraw(nil, nil, argv0) < 0)
sysfatal("%s: %r", argv0);
if((mctl = initmouse(nil, screen)) == nil)
sysfatal("%s: %r", argv0);
if((kctl = initkeyboard(nil)) == nil)
sysfatal("%s: %r", argv0);
pixi_init() ;
test_fb () ;
draw_fb () ;
enum{MOUSE, RESIZE, KEYBD, NONE};
Alt alts[4] = {
{mctl->c, , CHANRCV},
{mctl->resizec, , CHANRCV},
{kctl->c, , CHANRCV},
{nil, nil, CHANEND},
};
Currently I'm doing things for event handling like in a rio app and it works
but the code could be simplified by a notification layer which we can define
all together.
To make things more clear :
I have a working kiosk and an experimental window system but those can be
improved and I would prefer making those things a general well documented part
of the system. The more people experiment with such an enhancement the more it
evolves and the less bugs will remain. I have ideas and I'm sure others also
have ideas so it would be best to share opinions and learn from each other. I
don't like forking a project when I like its progress as I do regarding 9front
legacy9.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M5b9c63bb91f21f3264e973ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] suggestion : new service targets for plan9
I developed a kiosk version of plan9 (based on 9front and legacy9) and am about to develop a single user desktop system. Those can coexist with the existing plan9 system. I named the new service targets kiosk and desktop. Both work without rio. Currently I used initdraw, initmouse, initkeyboard, loadimage, flushimage from devdraw to avoid breaking of compatibility with the existing plan9 systems while the whole rendering of the windows is framebuffer based. Instead of the usual plan9 fonts I used regular truetypefonts. So my suggestions would be : 1) Define new service targets kiosk and desktop (Currently I do this in init or /user/.../lib/profile. This makes it possible for a user to start an alternative window manager or even a single applicaton (kiosk service) with a modern look and feel. 2) Define a layer between vga and devdraw perhaps vgafb which improves the performance for frame buffer rendered window managers. 3) Define events for mouse, keyboard, touchpad, windows which is based on notes managed by light threads inside the client app. Those three steps would protect the existing plan9 from changes and make it possible to only use the kernel, libraries, tools from alternative user interfaces. Plan9 is one of the smallest operating systems accompanied with a compiler and an abstraction which would attract much more developers and users if it had a modern user interface. We don't have to throw away anything and rio would even be able to run inside a window of a modern desktop. Plan9 has everything necessary to make it an attractive system not only for a handful of developers. The compilers, the portability, 9p, unicode, direct support for video hardware and its small size are fascinating. The only reason why it isn't recognized by more people is its GUI. I don't get the reason why we wouldn't extent it so we can use other GUI's while keeping the existing in respect of the developers who created this system. I will integrate this changes but I would prefer staying fully compatible to the existing projects legacy9 and 9front even more I would prefer not forking any of them but sharing my parts as contributions. What I need and what those changes need is a separation level between devdraw and the graphics hardware and a new event mechanism which can be based on notes or equals. I'm not a native English speaker so excuse the many mistakes. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mb4eb2005f779e611cdef4de4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
Thanks for your hint ori, After searching for Copying, Copyright, Licence I found these problematic commands (libs) : Xen (9f) diff (9f,l9) patch (9f, l9) ghostscript (9f, l9) mp3dec (9f, l9) lzip (l9) 9f ... 9font l9 ... legacy9 I'm not sure how problematic icclib could be. Clause 4 could be dangerous regarding ... derived from based on ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M691a23bfdc9732e512f2c59e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
I'm lucky cause I don't need ghostscript, page (depending on it) the fonts. I'm using a framebuffer renderer instead of rio for my tiny kiosk version of 9front. My code depends on the bootloader, the drivers, kernelcode, libraries from 9front. Especially the WiFi-drivers, usb support ramfs and loop-devices as implemented by 9front and those are all MIT licenced as far as I understood. Do you have a recommended copyright notice which I can display or would you prefer links to p9f, legacy9 and 9front while displaying the MIT licence. My distribution will be closed source but I intend to share some parts with the community. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M217d6926bc7bec6f0010b6ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] licence question
Thanks hiro. Regarding ghostscript : In plan9-2e this was written in README.Plan9 > Aladdin Ghostscript has been licensed to be included with the > release of Plan 9. Minor changes were made to the sources to > accommodate a couple of restrictions in the APE library and to > produce Plan 9 output formats. These changes are all conditioned > by > #ifdefPlan9 > and were made in December, 1994. As well, the build was rearranged > to be driven by a Plan 9 mkfile. > After Realease 4 the ghostscript version was updated and in the folder cmd/gs/doc/public.html is part of the distribution and that isn't conforming to the MIT licence. 3 2 Restrictions makes commerical use without a written licence from Aladdin imposible. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Mdd05931d4e2661b1a72664b6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] licence question
I noticed that I can't distribute fonts and ghostscript as part of a plan9 (9legacy, 9front) system due to their licensing terms. Does anybody know about code, libraries, binaries, documentation present on the latest 9legacy or 9front iso's which are outside the newly applied MIT-licence ? Thanks in advance -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-Maff4663e2d5388dab6291a84 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9vx, 9legacy
For everyone interested : On 64 bit debian systems you need to install the X11 compatibility libraries with sudo apt-get install libx11-dev:i386 sudo apt-get install libxext-dev:i386 The same syntax is for the other libraries mentioned by David necessary. Afterwards it compiles without problems and 9vx runs like a charm. I could compile programs and edit sourcefiles in the host translate under plan9 and its really fast. Thanks David and everyone involved in 9vx and vx32 thats what I need to write software for plan9. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf651d537d5dbd117-Mee8b78c21e82acb98a36e6c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9vx, 9legacy
Thanks for your fast reply, I'll try to find the way to install X11 compatibility libraries for debian 64 bit systems. > > a) When I typed fshalt I got an error that I don't have permissions to > call /bin/echo. It seems like echo from the host system was called > instead of echo from 9legacy. Is this a bug or did I forget something ? > > > I'm not sure what is your issue here. Anyway, you don't need to > run fshalt on 9vx, because there is usually no file system running. I wasn't sure why echo from the host was called out of the guest and if I have forgotten something to initialize. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf651d537d5dbd117-M6896134682f796ce1f89a5c4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9vx, 9legacy
While looking for a way to exchange files between a linux system and an hosted virtual machine running plan9 I found vx32 and 9vx. I couldn't master to compile it under a 64 bit Linux cause libX11 was missing as a compatible 32 bit library so I installed a 32 bit linux and everthing compiled without problems. I started 9legacy with 9vx -r -u glenda "memsize=1536" everything went fine and this is amazingly fast. I can exchange files between host and guest. Now my questions : a) When I typed fshalt I got an error that I don't have permissions to call /bin/echo. It seems like echo from the host system was called instead of echo from 9legacy. Is this a bug or did I forget something ? b) How does the installation procedure work ? Usually during the installation of a distro lets say 9front I would have to partition a harddisk where the necessary things are installed. c) I'm a bit confused about the licensing of 9vx and vx32. vx32 is LGPL and 9vx is/was licenced with the Lucent license while 9vx uses vx32 or am I wrong ? Thanks in advance and 9vx is really an amazing tool. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf651d537d5dbd117-M67a20cd6deb2da053b42096a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] ISO file with MIT licenced parts of plan9 and contributions.
Would it be possible for the plan 9 foundation to assemble an iso file with all parts of plan 9 and contributed code as downloadable from the website where in the root folder the new MIT license could be placed so that developers exactly know what is really part of this new license ? As an example http://9p.io/sources/contrib/steve/ contains the cfront package with sources. As far as I know cfront is licensed differently but the header of the site states that all those contributed sources are licensed with the MIT license. The only people who exactly know what was relicensed are the members of the plan 9 foundation. A statement at the header of a webpage isn't really assuring for developers who intend to take the code and base their future development on that. There are also packages in those folders which where GPL licensed in the past and as far as I know it's nealy impossible to relicense packages from GPL back to more permissive licenses when more than a few people worked on those projects. The situation seems clear for the four released plan9 CDs but regarding the n/sources/contrib folder it would be nice if the foundation could make things clearer. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T5b54eef0e245eb0f-Mcaa73711e92ce01de352da65 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] searching advice
First of thank you for your replies and sorry that I couldn*t reply immediatly. Anthony : I forgot the partition part in the command cause plan9 didn't recognize the ext2 partition in a virtual drive created with fdisk from my linux command line. There where only the entries raw and ctl below /dev/sdD0 so I wasn't sure if they would appear after a mount from the device. It seems that virtual hard disks created with fdisk from linux command line are in some way misinterpreted. After creating it with a gparted out of a qemu session my data partition was recognized and I used your modified command. Thanks for your advice. In the meantime I read also about u9fs and 9pfuse from plan9port and decided to give this feature a try cause this will eliminate the risks caused by write accesses from host and guest at the same time. Mack Wallace : Thank you for your advice. That should really be the way to share data between host and guest over qemu because it will be portable to my real needs after this testing setup. Like you I'm about to port an educational kiosk app realized with Freebsd and X11 to plan9 after the licence conditions changed. So I have to do a lot of coding and even while I loved some ideas of acme it wouldn't be the right choice for my students to work with acme on software projects. So I want to port my full developer environment to plan9 including a rio substitute and a forked scintilla Editor with syntax highlightning. To do that I need to exchange data between host and guest on a live base and u9fs as well as 9pfuse seem to do a better job regarding synchronization. The more I read the more I like the ideas how the kernel and drivers are implemented and of course 9p as the connecting glue. I'll try your u9fs advice parallel to the 9pfuse approach and share those information as an how to for my students and will be happy to mention your advice as well. I think that 9pfuse will make my live easier cause of the authentification demands of freebsd. I'll try this and reply ... thanks. Skip Tavakkolian : I didn't know this command thanks for reminding. The device was already recognized and the subfolders raw as well as ctl were present only the partitions on the drive weren't recognized and this was caused by the tool I used to create the virtual harddisk. For all who are interested fdisk from plan9 (9legacy) has a small but strong bug. While editing the partition table and trying to reset the changes a system crash ocured. Conclusion : I'm really impressed about the fast and very good replies to my question. Thank you I'll keep you informed about how I did the communication between host and guest cause this is somewhat lacking in available documentation. Many developers will give plan9 after the licence change a try cause it is a real alternative to even BSD licenced open source projects. To realize my kiosk setup with FreeBSD I have to supply an iso image for the last version with 1 GB while only using the kernel and xinit. The reasons are first of all the llvm infrastructure which has the largest size in the setup (320 MB and more) and X11 where the minimal setup requires 840 MB. By switching to plan 9 I estimate getting a working kiosk app with a size of less than 128 MB while keeping the compiler suite and the protocols intact. Especially for people who need a general setup of computers in lessons this licence change opened up many possibilities. So a live exchange of data between developer systems during the modification time of userland software and windowing system is unavoidable. Thanks for your replies. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T267dbe605a36a2f5-Me7e86568d604d2c1428f0174 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
