Re: [9fans] Raw Input Driver
On Fri, Mar 20, 2009 at 01:03:12PM +, roger peppe wrote: > > the problem with choosing a higher level of abstraction is that > the input event generators can't in general be agnostic about > what the mouse/keyboard/whatever are operating on, > so you end up with a smart client or split application, > which lack the same easy composability that you get > from plan 9's remote devices. For my own stuff, having to rewrite the 2 dimensions user interface, I have created a library running on the terminal that keeps the definitions of the graphical elements drawn with an identifier (3 members) giving to the processing unit (remote) a mean to unambiguously identifies the antecedent for processing. This has a lot of advantages. The UI is just a _representation_ of the data (and in fact of the commands by means of labels/buttons). All the user wandering on the UI, including selecting things, is done on the terminal. Since identifying an element (vectorial elements for KerGIS vectorial stuff; or cell for a grid etc.) is indeed identifying the representation of the element, there is no acrobatics trying to convert the transformation leading to the window, the 1, 2 or 3 pixels between the hot spot of the pointer and the element (in a GIS, converting the distance between pixels to a ground distance and searching the element in ground coordinates), but instead, using the representation for what it is, so searching the representation near 1, 2 or whatever pixel tolerance the representation is near (indeed reducing the search to what is displayed, including ability to mask), and then only sending back the identifier for the real element to processing. This fundamental split between the representation, i.e. the UI, and the processing is the fundamental flaw of the X11 approach which has put the articulation (the network) on the wrong place: in X11, all the UI handling, except dispatching window events, is done on the processing unit (the client in X11 terminology). -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Raw Input Driver
On Fri, Mar 20, 2009 at 02:26:02PM +, roger peppe wrote: > > that's fine for location-based events, e.g. from a mouse, > (well, fine for largely static UIs) > but still leaves unresolved the issue of how do deal with > events that are agnostic about their destination, such > as keyboard events. you can't decide which graphical > element a key press is destined for until you know the > mouse language of your application. acme has both click-to-type > and point-to-type - the client would need to know which one > to use, otherwise you still have exactly the same ordering > problem as before. In my design, there is a "virtual machine" (?), a software processing unit (?) on the terminal, stack based, so that when you are gathering events on a window, whether pointer location-based, or button events (location agnostic except for the window it is sent in), a task "returns" and can sent a software button event to dequeue the previous task on the stack that fires the processing. Or that can requeue an action if the data is not finished. For a kind of example, when drawing a line, you can just "point" a vertex (corresponding ground coordinates will be computed from window coordinates) or request to fasten on an element which means doing supplementary processing. In this case, on the terminal, the elements proposed for fastening are displayed and the user chooses. Only when the element is chosen, a request back (a "store") is sent since the representation of the elements is not homomorphe (i.e. due to scale, the drawing of a n vertex element is not perhaps a n vertex line on screen, so the mth vertex in the representation is generally not the mth vertex in the antecedent). The drawing task is dequeued and the processing fired. Only when, on the processing unit, the new vertex is computed, a new task is queued to continue drawing. I may misunderstand the point both due to my lacks in english and to the fact that I'm involved in my own implementation needs. But my software system is so large and touches so many different types of data, and needs to accomodate so many different types of UI, that I don't understand how a, at least chunk by chunk, terminal problem can not be terminal handled. At the moment, I have made improvements, and modifications (mainly simplifications); there are times when one can not avoid interrupting and sending to processing; but the principles hold. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Raw Input Driver
Im my previous message, obviously: s/queue/push/g s/dequeue/pop/g -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] typed sh (was: what features would you like in a shell?)
I don't know if others have already hit this kind of problematic, but I was dealing with a fair amount of C code, usable both as a library and accessible by a shell. Plus debugging needs. So I was, again and again, writing a wrapper to access a C function from the shell. So I ended concluding that I needed a kind of C interpreter as a shell. (I have an implementation, but it is not pure C---sentential calculus is distinct; it's a 4 values logic (NONSENSE, TRUE, FALSE, UNDECIDABLE) that has already real application in geometrical calculus; and integer and real calculus is added too for mathematical tasks---but it is not ready for prime time and I have still unanswered questions for special things I want to be present.) typedef, i.e. the ability to define other types above primary ones is perhaps what you are looking for? ISTR that on the early PCees, there was a basic interpreter in BIOS to let you play with the almost bare machine. I'd like to have a shell that lets me play with the bare OS. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] noweb and literal programming
On Sat, Apr 11, 2009 at 04:53:44PM +0200, Rudolf Sykora wrote: > In contrast, noweb tried to be simpler, with no tight connection to > the language used (any language can be used) and no tight connection > to the formatter. and no tight connection with any usage either. [Sorry, couldn't resist since "CWEB is hard" can be only sustained by people who don't use it.] Will be quiet now (since having work using CWEB). -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] VMs, etc. (was: Re: security questions)
On Fri, Apr 17, 2009 at 11:32:33AM -0500, blstu...@bellsouth.net wrote: > - First, the gap between the computational power at the > terminal and the computational power in the machine room > has shrunk to the point where it might no longer be significant. > It may be worth rethinking the separation of CPU and terminal. > For example, I'm typing this in acme running in a 9vx terminal > booted using using a combined fs/cpu/auth server for the > file system. But I rarely use the cpu server capability of > that machine. I'm afraid I don't quite agree with you. The definition of a terminal has changed. In Unix, the graphical interface (X11) was a graphical variant of the text terminal interface, i.e. the articulation (link, network) was put on the wrong place, the graphical terminal (X11 server) being a kind of dumb terminal (a little above a frame buffer), leaving all the processing, including the handling of the graphical interface (generating the image, administrating the UI, the menus) on the CPU (Xlib and toolkits run on the CPU, not the Xserver). A terminal is not a no-processing capabilities (a dumb terminal): it can be a full terminal, that is able to handle the interface, the representation of data and commands (wandering in a menu shall be terminal stuff; other users have not to be impacted by an user's wandering through the UI). More and more, for administration, using light terminals, without software installations is a way to go (less ressources in TCO). "Green" technology. Data less terminals for security (one looses a terminal, not the data), and data less for safety (data is centralized and protected). Secondly, one is accustomed to a physical user being several distinct logical users (accounts), for managing different tasks, or accessing different kind of data. But (to my surprise), the converse is true: a collection of individuals can be a single logical user, having to handle concurrently the very same rw data. Terminals are then just distinct views of the same data (imagine in a CAD program having different windows, different views of a file ; this is the same, except that the windows are on different terminals, with different "instances" of the logical user in front of them). The processing is then better kept on a single CPU, handling the concurrency (and not the fileserver trying to accomodate). The views are multiplexed, but not the handling of the data. Thirdly, you can have a slow/loose link between a CPU and a terminal since the commands are only a small fraction of the processing done. You must have a fast or tight link between the CPU and the fileserver. In some sense, logically (but not efficiently: read the caveats in the Plan9 papers; a processor is nothing without tightly coupled memory, so memory is not a remote pool sharable---Mach!), even today on an average computer one has this articulation: a CPU (with a FPU perhaps) ; tightly or loosely connected storage (?ATA or SAN) ; graphical capacities (terminal) : GPU. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] VMs, etc. (was: Re: security questions)
On Fri, Apr 17, 2009 at 01:29:09PM -0400, erik quanstrom wrote: > > In some sense, logically (but not efficiently: read the caveats in the > > Plan9 papers; a processor is nothing without tightly coupled memory, so > > memory is not a remote pool sharable---Mach!), > > if you look closely enough, this kind of breaks down. numa > machines are pretty popular these days (opteron, intel qpi-based > processors). it's possible with a modest loss of performance to > share memory across processors and not worry about it. NUMA are, from my point of view, "tightly" connected. By loosely, I mean a memory accessed by non dedicated processor hardware means (if this makes sense). Moving data from different memories via some IP based protocol or worse. But all in all, finally a copy is put in the tightly connected memory, whether huge caches, or dedicated main memory. The disaster of Mach (I don't know if my bad english is responsible for this, but in the Plan9 paper the "research" or "university" OS that is implicitely gibed at is Mach) is a kind of example. NUMA are sufficiently special beasts that the majority of huge computing facilities have been done by clusters (because it was easier for software only organizations). This definitively doesn't mean NUMA has no raison d'être. On the contrary, this is an argument supplementary to the distinction between the UI (terminals) and the CPU. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] VMs, etc. (was: Re: security questions)
On Fri, Apr 17, 2009 at 01:31:12PM -0500, blstu...@bellsouth.net wrote: > > Absolutly, but part of what has changed over the past 20 > years is that the rate at which this local processing power > has grown has been faster than rate at which the processing > power of the rack-mount box in the machine room has > grown (large clusters not withstanding, that is). So the > gap between them has narrowed. This is a geek attitude ;) You say that since I can buy something more powerful (if I do not change the programs for fatter ones...) for the same amount of money or a little more, I have to find something to do with that. My point of view is: if my terminal works, I keep it. If not, I buy something cheaper, including in TCO, for happily doing the work that has to be done ;) I don't have to buy expensive things and try to find something to do with them. I try to have hardware that matches my needs. And I prefer to put money on a CPU, more powerful, "far" from average user "creativity", and the only beast I have to manage. > > > The processing is then better kept on a single CPU, handling the > > concurrency (and not the fileserver trying to accomodate). The views are > > multiplexed, but not the handling of the data > > That is part of the conversation the question is meant > to raise. If cycles/second isn't as strong a justification > for separate CPU servers, then are there other reasons > we should still have the separation? If so, do we need > to think differently about the model? The main point I have discovered very recently is that giving access to the "system" resources is a centralized thing, and that a logical user can have several distinct sessions on several distinct terminals, but these are just "views": the data opened, especially for random rw is opened by a single program. Fileservers have only to provide what they do provide : 1) Random read/write for an uniq user. 2) Append only for shared data. (In KerGIS for example, some attributes can be shared among users. So distinct (logical) users can open a file rw, but they only append/write and the semantics of the data is so that appending the n+1 records doesn't invalidate the [0,n]---records are partitions, there is no overlapping. Changing the records (random access) is possible but the cases are rare, and the stuff is done by the user manager (another logical user)). So the semantics of the data and the handling of users is so that a user can randomly read/write (not sharable). A group can append/write but without modifying records. And others can only (perhaps) read. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Fri, Apr 17, 2009 at 08:16:40PM +0100, Steve Simon wrote: > I cannot find the reference (sorry), but I read an interview with Ken > (Thompson) a while ago. > > He was asked what he would change if he where working on plan9 now, > and his reply was somthing like "I would add support for cloud computing". > > I admin I am not clear exactly what he meant by this. My interpretation of cloud computing is precisely the split done by plan9 with terminal/CPU/FileServer: a UI runing on a this Terminal, with actual computing done somewhere about data stored somewhere. Perhaps tools for migrating tasks or managing the thing. But I have the impression that the Plan 9 framework is the best for such a scheme. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] VMs, etc. (was: Re: security questions)
On Fri, Apr 17, 2009 at 04:25:40PM -0500, blstu...@bellsouth.net wrote: > > Again, that's not to say that there aren't other valid motivators > for some centralized functionality. It's just that in my opinion, > we're at the point were if it's raw cycles we need, we'll have > to be looking at a large cluster and not a simple CPU server. Well there is perhaps a hint about what we disagree about. I'm not using CPU with the strict present meaning in Plan 9 but as a _logical_ processing unit (this can actually be, in this scheme, a cluster or whatever). This does not invalidate the logical difference between a terminal and "a" CPU. A node can be both a CPU (resp. member of a CPU) and a terminal etc. The plan 9 distinction, on the usage side et on the topology, between FileServer, CPU and Terminal is sound and fundamental IMHO. Enough for me at the moment since, even if I have some things on the application side, for the rest my discussion of "cloud computing" could be a discussion about "vapor computing" ;) -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Fri, Apr 17, 2009 at 03:15:25PM -0700, ron minnich wrote: > if you want to look at checkpointing, it's worth going back to look at > Condor, because they made it really work. There are a few interesting > issues that you need to get right. You can't make it 50% of the way > there; that's not useful. You have to hit all the bits -- open /tmp > files, sockets, all of it. It's easy to get about 90% of it but the > last bits are a real headache. Nothing that's come along since has > really done the job (although various efforts claim to, you have to > read the fine print). My only knowledge about this area is through papers and books so very abstract. But my gut feeling, after reading about Mach or reading A. Tanenbaum (that I find poor---but he is A. Tanenbaum, I'm only T. Laronde), is that a cluster is above the OS (a collection of CPUs), but a NUMA is for the OS an atom, i.e. is below the OS, a kind of "processor", a single CPU (so NUMA without a strong hardware specifity is something I don't understand). In all the mathematical or computer work I have done, defining the element, the atom (that is the unit I don't have to know or to deal with what is inside) has always given the best results. Not related to what you wrote but the impression made by what can be read about this "cloud computing" in the open sewer: A NUMA made of totally heterogeneous hardware with users plugging or unplugging a CPU component at will. Or a "start-up" (end-down) providing "cloud computing" with as the only means the users' hardware connected is perhaps a WEB 3.0 or more, a 4th millenium idea etc. but is for me at best an error, at worst a swindle. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
[I reply to myself because I was replying half on two distinct threads] On Sat, Apr 18, 2009 at 01:59:03PM +0200, tlaro...@polynum.com wrote: > > But my gut feeling, after reading about Mach or reading A. Tanenbaum > (that I find poor---but he is A. Tanenbaum, I'm only T. Laronde), > is that a cluster is above the OS (a collection of CPUs), but a > NUMA is for the OS an atom, i.e. is below the OS, a kind of > "processor", a single CPU (so NUMA without a strong hardware specifity > is something I don't understand). > > In all the mathematical or computer work I have done, defining the > element, the atom (that is the unit I don't have to know or to deal with > what is inside) has always given the best results. The link between this and the process migration is that, IMHO or in my limited mind, one allocates, depending on resources available at the moment, once and for the process duration, a node. This is OS business : allocating resources from a cluster of CPUs. The task doesn't migrate between nodes, it can migrate "inside" the node, from core to core in a tightly memory space coupled CPU (a mainframe, whether NUMA or not) that handles failover etc. But this is infra-OS, "hardware" stuff and as far as the OS is concerned nothing has changed since the node is an unit, an atom. And trying to solve the problem by breaking the border (going inside the atom) is something I don't feel. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Sat, Apr 18, 2009 at 08:05:50AM -0700, ron minnich wrote: > > For cluster work that was done in the OS, see any clustermatic > publication from minnich, hendriks, or watson, ca. 2000-2005. Will do. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Sat, Apr 18, 2009 at 12:20 PM, ron minnich wrote: > > I'll say it again. It does not matter what we think. It matters what > apps do. And some apps have multiple processes accessing one file. > > As to the wisdom of such access, there are many opinions :-) > > You really can not just rule things out because reasonable people > don't do them. Unreasonable people write apps too. There are, from times to times, lists of "Worst IT jobs ever". I _do_ think yours should come first! Having to say: "yes" to an user... Br... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] automatic page sharing
On Sat, Apr 18, 2009 at 07:05:07PM +0200, Enrico Weigelt wrote: > > Assuming statically linked-in libraries are properly aligned, > we'll have lots of equal pages in the system, so the kernel could > find and automatically map them together. > Well that's one of the 3 classical options: 1) static linking. 2) static shared libraries [your proposal] 3) dynamically linked shared libraries. For what is worth, you can find explanations in "Linkers and Loaders" by John R. Levine, Morgan Kaufmann, ISBN 1-55860-496-0. HTH, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] "FAWN: Fast array of wimpy nodes" (was: Plan 9 - the next 20 years)
On Sun, Apr 19, 2009 at 09:27:43AM -0500, Eric Van Hensbergen wrote: > > I'm not convinced that such ad-hoc DSM models are the way to go as a > general principal. Full blown DSM didn't fair very well in the past. > Plan 9 distributed applications take a different approach and instead > of sharing memory they share services in much more of a message > passing model. This isn't to say that all caches are bad -- I just > don't believe in making them the foundation of your programing model > as it will surely lead to trouble. > FWIW, the more satisfying definition for me of a "computing unit" (an "atom" OS based) is memory based: all the processing unit having direct hardware access to a memory space/sharing the same directly hardware accessible memory space. There seems to be 2 kinds of "NUMA" around there : 1) Cathedral model NUMA: a hierarchical association of memories, tightly coupled but with different speeds (a lot of uniprocessor are NUMA these days with cache1, cache2 and main memory). All directly known by the cores. 2) Bazaar model NUMA, or software NUMA, or GPLNUMA: treating an inorganized collection of storage as addressable memories since one can always give a way to locate the ressource, including by URL, associating high speed tightly connected memories with remote storage accessible via IP packets sent by surface mail if the hardware drived whistle is heard by the human writing the letters. Curiously enough, I believe in 1. I don't believe in 2. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Sat, Apr 18, 2009 at 08:05:50AM -0700, ron minnich wrote: > > For cluster work that was done in the OS, see any clustermatic > publication from minnich, hendriks, or watson, ca. 2000-2005. FWIW, I haven't found much left, and finally purchased your (and al.) article about HARE: The Right-Weight-Kernel... Since it considers, among others, Plan 9, it's of much interest for me ;) What impresses me much is the state of the open source cluster solutions from a rapid tour. clustermatic: not much left from lanl openmosix: closed beowulf: seems to have stalled a little since 2007 kerrighed: "After 8 years of research it is considered a proof of concept", but "for obtaining a stable system, we have disabled some features". I hope that the last [from memory] quotes do not imply that the old way of disproving an assertion by a counter-example has been replaced by considered proved an assertion by advertising a limited not crashing too fast example. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 - the next 20 years
On Fri, Apr 24, 2009 at 08:33:59AM -0700, ron minnich wrote: > > [snipped precisions about some of my notes] > > Not sure what you're getting at here, but you've barely scratched the surface. The fact that I'm not an english native speaker does not help and my wording may be rude. This was not intended to say that clusters have no usage or whatever. This would be ridiculous. And I do expect that solutions that are indeed hard to get right are still used and not chosen or thrown away depending on the mood. Simply that, precisely, specially in the "open source", for somebody like me, who does not work in this area, but wants to have at least some rough ideas just to, if not write programs that can be used efficiently out of the box on such beasts, but at least try to avoid mistakes that make the program a nightmare to try to use such tools (or impact the design of the solutions, having to deal with spaghetti code), following what appears on the surface is disappointing, since it appears, disappears, and the hype around some solutions is not always a clear indicator about the real value, or emphasize something that is not the crux. In my area, the "watershed" computation on a grid (raster) for geographical informations is a heavy process stuff, and processing some huge data calls for solution both on the algorithmic side (including the implementation), and on the processing power. So even if I'm not a specialist, and don't plan to be (assuming I could understand the basics), I feel compelled to have at least some ideas about the problems. For this kind of stuff, the Plan 9 organization has given me at least some principles and some hard facts and tools: separate the representation (the terminal) from the processing. Remember that processing is about data that may not be served by the same instance of the OS, i.e. that the locking of data, "ensured" during processing is, on some OS and depending on the fileserver or filesystem, "advisory". So perhaps think differently about rights and locking. And, no, this can not work in whatever environment or with whatever i filesystem and fileservers. And adding Plan 9 to POSIX, showing the differences is a great help in organizing the sources to, between guarantedd by C, and system dependant for example. After that, my only guidelines are that if some limited, calculus intensive sub-tasks can be made in parallel but the whole is interdependant, one can think about multiple threads sharing the same address space. But if I can design my data formats to allow independant processing of chunks (locality in geometrical stuff is rather obvious ; and finally sewing all the chunks together afterwards, even with some processing on the edges of the chunks), I can imagine processes (tasks) distributed among distinct CPUs. In this case, an OS can, too, launch the tasks on the same CPU with multiple cores. At the moment, I think more on multiple tasks, than threads. But that's vague. I know what to avoid doing, but I'm not sure that what I do is not to be added to the list of "don't do that" things. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Google finally announces their lightweight OS
On Wed, Jul 08, 2009 at 10:48:58AM +0300, Aharon Robbins wrote: > http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html > > 'nuff said. :-) Is it my english that is not sufficient ? [Note: it is written "Google Chrome" while I think it should be "Google Chrome OS"] "The software architecture is simple - Google Chrome running within a new windowing system on top of a Linux kernel." If I read correctly, this is not Plan9 based. And it seems a "terminal" will be available as open source, while the apps and the data will be in a cloud... that is not controlled by the user. (I have nothing against closed source---I make it too---. But the terminal is definitively not the bulk of a cloud. Everybody being allowed to build and sell terminals, ok. But terminals to access what belonging to who?) The majority of the current thinking is re-discovery of Plan 9 architecture: separate terminal, CPU and fileserver. And Plan9 was thought with SMP from the beginning. So why all is always "Linux based" ? And no, I have no problem accessing my data wherever I go, because it is _my_ data. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Google finally announces their lightweight OS
On Wed, Jul 08, 2009 at 10:02:59AM +0100, Richard Miller wrote: > > So why all is always "Linux > > based" ? > > Because linux has an army of volunteers hacking up drivers for > everybody's weird undocumented ever-changing hardware. But if it is just for a terminal, there is a lot of drivers you don't need. (Well, the video card is generally not the easier to correctly drive...) -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Google finally announces their lightweight OS
On Thu, Jul 09, 2009 at 02:47:37PM -0500, Jason Catena wrote: > > Yes, sorry I didn't look it up earlier. > > Bentley, J., Knuth, D., and McIlroy, D. 1986. Programming pearls: a > literate program. Commun. ACM 29, 6 (Jun. 1986), 471-483. DOI= > http://doi.acm.org/10.1145/5948.315654 [The article is reproduced in D. E. Knuth, "Literate Programming", CSLI ISBN 0-9370-7380-6] For the task to be done "print the k most common words in a file", the Unix approach and the Unix tools give everything to create a "program" far more rapidly than the from scratch approach adopted by D. Knuth. But because the tools exist (are already written... but in what language? Easily understandable? Maintainable? etc.). But this does not mean that _in general_, literate programming has not its strength especially for complex and weaven program... or even for writing the tools, the bricks one combines in a pipeline like McIlroy does. I don't think that TeX and METAFONT could have been written correctly, or could be understandable in something else than WEB (unfortunately not CWEB; that would simplify greatly "porting"). [For another thread: MetaPOST can be used instead of gnuplot. But not easily for 3D like plotting. Unfortunately, MetaPOST too is WEB not CWEB. And the ad hoc conversion of some Pascal to C (web to C) seems alas the simplest way. Even the Pascal compilers that could be ported to compile on Plan9 (if there are) would probably not allow a straightforward compilation of the WEB based programs.] -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Google finally announces their lightweight OS
On Thu, Jul 09, 2009 at 06:18:14PM -0400, erik quanstrom wrote: > > it's also interesting to notice that long comments > are often associated with bugs. Literate programming is a magnifying glass. It's very easy to use, but it's not straightforward to use right. My first attempts with a "creative" problem, with lengthy explanations and so on, were only showing that I was beating around the bush and had no clear idea of what I was doing. It was the same with pure C, except it was not as obvious. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] plan 9 interface color ergonomy
Hello, Even if the plan 9 graphical interface doesn't look like the other ones, as a matter of fact it happens that I'm far less eyes-tired by the plan 9 one than with others---indeed, if I like more the console on Unix like system it's because glyphes are bigger and the black background less aggressive to my taste. I know that the human eye "sees" (or the human brains interprets) more green shades than red or blue. So if plan 9 feels more comfortable (for me at least) this is probably linked to this color choice. (It's curious to see that the themes proposed by other systems almost never propose a green based one: too "natural", so not sufficiently "artefact", human made, "professional"?) I seem to recall reading a paper by Rob Pike about discussions, I think with Renée French, about this visual aspect. But I don't manage to find back which one it was, and if there are other ones about this ergonomy. Has somebody hints? TIA -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] plan 9 interface color ergonomy
Thanks for the pointer(s)! The extra information, compared to what I previously read, is Edward Tufte. I do think Plan 9 colors choices are right. In french, "travail" (work) is derived from a word meaning pain, torture. That's perhaps why a "professional" computer interface is one that gives you pain, since it must be work... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] pc with floppy but without cd/dvd
FWIW, there is the solution to bootstrap the install with another mean on a floppy. For example, using GRUB with serial line to load a plan9 install kernel (not tested). Or to use etherboot (gPXE) on a floppy to load a PXE version. Just to say that the remove of the floppy mean doesn't render plan9 uninstallable on a floppy only machine, but impose an external mean to load/bootstrap. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Woes of New Language Support
On Sun, Jul 26, 2009 at 09:48:23AM -0400, erik quanstrom wrote: > > my opinion (not that i'm entitled to one here) is > that the unicode guys screwed up. unicode is not > consistant. explain why there are two code points sigma. > 03c3 greek small letter sigma > 03c2 greek small letter final sigma They are distinct in ancient greek at least. The glyph is not the same whether the letter is inside or at the end of a word. (At the beginning, in ancient greek, there was indeed no blanks between words but just a stream of chars...) Or perhaps did I misunderstand what you wrote. Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] installation on SATYA disk failed
On Sun, Jul 26, 2009 at 08:51:54PM +0100, Ethan Grammatikidis wrote: > I forgot the obvious: Install a bootloader capable of booting CD-ROMs to a > floppy. This won't help if the BIOS doesn't support El Torito, since a bootloader has generally no drivers (except for ethernet perhaps), and since the bootloaders able to handle CDROM don't see the CDROM but what is faked as a floppy (not only 3"1/2) or a hard drive (rare) by the BIOS. Hence, if the BIOS doesn't support El Torito, a bootloader only on a floppy won't give access to the CDROM. That's also why when you start wanting to extend capabilities of a bootloader you realize, too late, that you are creating another kernel... and it's simpler to use a stripped kernel as the main part of the bootstrap machinery. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] just an idea (Splashtop like)
On Sat, Aug 01, 2009 at 07:58:10AM -0400, erik quanstrom wrote: > > why not just use normal hardware and buy a DOM for it? > none of coraid's machines, including the fileserver (!) have > spinning media. only the srs (coraid storage appliances) do. > > you can get a 128mb pata dom for $13 and sata for $30 > at memorydepot.com (not an endorsement but i've purchased > from them before.) Well, if the DOM is compatible with traditionnal IDE it could be, too, an option for installation: an easily pluggable HD instead of floppy or CD. I didn't even know that this exists... so thanks for the tip, Erik! -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 07:05:31PM -0300, Iruata Souza wrote: > > that's just what 9null is: new pbs, 9pcload (bootstrap kernel), > /boot/boot using rc(1) scripts. > instead of a 'root from' you may get a 'kernel is at' prompt to which > you can ask for a shell (!rc) Thank you for doing this. I worked years ago to add El Torito and uncommon floppy formats to Grub just to realize that adding fs drivers, ethernet drivers, shell like scripting we were just reinventing the wheel i.e. a kernel, that was never efficient enough to recover a system when there was a problem, and generally too complex for normal use when it was just booting as usual. It is simpler to be fs agnostic and load a sequence of sectors. (Just as a note, there was at some time a tarfs with some BSD to have a kind of organized stream of sectors. No incentive or whatever, just a note about the same kind of principles or tracks followed somewhere else.) Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] nice quote
On Thu, Sep 03, 2009 at 04:24:50AM -0700, Skip Tavakkolian wrote: > > i think by now most of us expect new ornamentation added to C++ > periodically. it is surprising that this is being considered seriously > for C. > I'd like to say that my distate for C++ is purely technical, but to be honest, I'm not quite sure. I have the principle that, since a programming language aims to express clearly what you want to be done, if the author doesn't explane clearly his language, there is a problem. K&R is beautiful in this respect. In contrast, I never managed to bite in Stroustrup's description. But the whole story is that, during my childhood, there was the Muppet's. And a character was a swedish cook, whose name was almost impossible to pronounce, whose recipes were not understandable, and whose results were not engaging. And I fear that, behind the conscious, this has played a role... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] nice quote
On Thu, Sep 03, 2009 at 02:02:53PM +, Greg Comeau wrote: > In article <20090903120157.ga1...@polynum.com>, wrote: > >I have the principle that, since a programming language aims to express > >clearly what you want to be done, if the author doesn't explane clearly > >his language, there is a problem. > > > >K&R is beautiful in this respect. In contrast, I never managed to > >bite in Stroustrup's description. > > Ok, now I'll get provocative: > Then why do so many people have a problem understanding C? Whether because there are too many people doing programming when they should not (including me). Or because they are trying to learn C from another book than K&R's. C shall be the test. If you don't even understand C, explained by K&R, then do something else. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] nice quote
On Sat, Sep 05, 2009 at 07:22:37AM -0400, Akshat Kumar wrote: > "Programming languages are just tools, after all." > > Considering that Plan 9 has only two inherent languages, > and its users often push for work to be done in only those, > what is the Plan 9 perspective of languages and tools in > relation to each other? I don't know for "the Plan 9 perspective" and have no authority to talk "for Plan 9", but since almost all interpreters or compilers are written in C, whether completely or the bootstapping procedure (a C core that is able to interpret a subset of the language to generate a binary for the non optimized version of a complete compiler etc.), there are all the tools as long as there is a C compiler for the machine. The remaining is, IMHO, user stuff: one has all tools needed to customize. The only "lack" in C is perhaps defined full control for arithmetic/calculus. That's probably why FORTRAN is still here and has still its strength in this area. Just my 2 centimes, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] nice quote
On Sun, Sep 06, 2009 at 05:51:33PM +0100, Eris Discordia wrote: > > I don't think we are actually in disagreement here. I have no objections to > your assertion. However, the particular case at hand indicates a different > thing than historians (of computer technology) "backporting" today's > trivial matters. I believe that a concept existed in a language > (Plankalkuel) but not the machine it was supposed to control (Z3) by all > [...] There is a rather extensive review of "The Early Development of Programming Languages" by Donald E. Knuth and Luis Trabb Pardo, reproduced and completed in "Selected Papers on Computer Languages", Donald E. Knuth, CSLI ISBN 1-57586-382-0 presenting the state and achievement, among many others, of Zuss Plankalkül (followed by Goldstine/von Neumann, Curry, Mauchly etc.). -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] linux stats in last year from linuxcon
On Mon, Sep 21, 2009 at 09:22:56AM -0700, ron minnich wrote: > 2.7M lines last year > 10K lines added a day. > 5K lines deleted per day. > > I keep thinking this can't be sustained. What happens next? Are there stats indicating where the lines are added? If this is new hardware (drivers), the accumulation is not a problem---if the API stays stable; if one needs to rework all the drivers because the API does not stabilized... The only time I had to dive in the Linux kernel code, I was disappointed by the "entropy" of the style and ended grep'ing or awk'ing all around to extract a (partial) list of PCI identifiers and drivers. (This was long ago now. 2002 ?) I wonder if a software project will some day be an example of a black hole: collapsing from its own size, the work needed to just make it work being greater than the resources available and the gain to have it work; and the inability to understand the whole (too much, too long) resulting in the impossibility to evolve... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Barrelfish
On Mon, Oct 19, 2009 at 12:13:34PM -0400, erik quanstrom wrote: > > 1. p. 8. "the most promising devices are quantum effect > devices." (none are currently in use in processors.) Since quantics means unpredictable, I think that we see more and more quantum effects in hardware and software. So, I beg to disagree ;) -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] go to this site
On Mon, Oct 26, 2009 at 05:00:53PM -0700, ron minnich wrote: > nebula.nasa.gov Well, at least the name makes sense for a french since in french nebula means too: hazy. Computer in the air. Fuzzy logic, and impalpable results (except for disasters which will be very palpable). -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
On Tue, Oct 27, 2009 at 12:37:58PM -0400, erik quanstrom wrote: > > there was also a bit of talk about os agnostic driver stubs. > i'm a little pessimestic about the chances for success there, > especially for oses that don't use the berkeley socket stuff. > but it's probablly something that's worth talking about. Wasn't there an "OS kit" or something like that with drivers derived from Linux one's at some moment? Found this some years ago when I was searching doc. about OSes---I seem to remember this was when looking for Mach (!) documentation, so could be CMU. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Two suggestions for ape (was: egrep for Plan9)
On Tue, Oct 27, 2009 at 08:23:10PM -0400, Dave Eckhardt wrote: > > University of Utah, "Flux OSkit". > > Old OSkit is mostly BSD licensed (if you count the CMU Mach license > as a BSD license), but at some point somebody sprayed the GPL over > everything (somewhat reducing the utility of some CMU-derived code > for a project here at CMU, but I digress). > > If you are looking for an approximation of the last non-GPL'd OSkit, > I think this is probably it: > > http://os.inf.tu-dresden.de/fiasco/download/fiasco-1.1-oskit.tar.bz2 Thanks to everyone for the pointers and the complementary informations about the status. The idea seems logical at first and even rewarding for hardware manufacturers (you can easily copy soft; cloning a device is more difficult at home and certainly not cheaper...), since the more OSes have drivers, the more customers can buy the devices. But since there is a kind of OS dominating, there is a bias. And since, more and more, even in "open" OSes, there are BLOBs... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] tex
On Tue, Dec 08, 2009 at 02:30:49PM -0800, ron minnich wrote: > On Tue, Dec 8, 2009 at 12:55 PM, Steve Simon wrote: > > somone was working on a modern port of TeX to plan9. > > did this work out? I would like to update my installation > > as I think I may be using LaTeX before long. > > I gave it a go but it wore me out. The pdflatex guys just destroyed > latex portability, and tex overall is far less portable than it was > years ago. It's a sad story. I gave it a try too, but it's stalled---no abandon, but I have already too much to do with the GIS. For whose who would give it a try (my plan was/is to get rid of all the GPL mess added, since TeX, METAFONT and the like are the stable parts; that's all the mess added around that is a hell): 1) I first thought about trying to get an open source Pascal compiler (there is at least one in the old BSD sources). There is/was a GNU project, or at least a GPL project too. But Pascal is not my cup of tea and I found messages from Donald Knuth, who was trying to compile the software with this (so that TeX depends on nothing else) and he finally gave up... Conclusion: if even he gave up, I should perhaps take another way... 2) Second way: translate WEB to CWEB. For the format, this is easy. But for the code, this is more or less what web2c does. So... 3) Retrieve the public version (Thomas Rockiki) of the original translation stuff, and restart from this. Personnally, my goal was only the core TeX and METAFONT, dvips and MetaPOST without kpathsea---I use TeX and not LaTeX, and no pdfTeX or the oriental extensions. A C89 translation will give the software to Unices and Plan9 and save the system from the "bazaar" touch that is the reciprocal of Midas': give it gold, it will give you crap. Let's hope someone takes this---I mean not compile the present mess, but trim down to a pure Donald Knuth's base. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] [Announce] CorTeX: the core of TeX
Hello, The subject was touched on a previous thread. Since I use a lot TeX, METAFONT and MetaPOST (with CWEB), I wanted to be freed from what has become a nightmare and a bloatware. So I have verified that this is feasible and has started with the following principles: 1) The Pascal way is a noway; so the TeX related stuff will be compiled with a C compiler. 2) I have retrieved an old (but post 3.0 for TeX) version of Web-to-C that was still public domain and unemcumbered with GPL or GNU stuff (getopts, kpathsea and so on). This is web2c version 5.0C (I don't know if there is a later version still public and GNU free, but I now don't care; it's fixed). 3) The only packages that will be handled by me (via the change files) are Donald Knuth's, Tomas Rokicki's dvips (mainly C), John Hobby's MetaPOST (before kpathsea and the like) and xdvi(1) (obviously this one will be of no use for Plan9). The data (macros and fonts) should be usable without much ado. (But I strictly don't care about LaTeX and the like: I use plain or my own macros. If someone wants this, she will have to test, on her own, with the core but without me.) 4) I have already handled the tangle/weave bootstrap and web2c utilities to know if this is achievable. They are POSIXLY compliant and they work in this preliminary tour. The remaining is an update of the change files. 5) The first step will be POSIX (this is mainly C89, but some signal handling and other sys dependant stuff are here). I will remove any Curses stuff, to build 1D programs that is _line_ oriented interface (as an example, the editor is ed(1); not vi(1)). It should compile under APE for Plan9 without problem. Since I'm late, as usual, with some business stuff for early 2010, don't expect news before end of January 2010. After verifying the current state (if one wants TeX, one must download an ISO DVD...), and verifying that I can have hope to continue using TeX on my own, I put this aside for the moment. Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] [Announce] CorTeX: the core of TeX
On Wed, Dec 16, 2009 at 08:02:03PM +0100, Frederik Caulier wrote: > That's great news, if you need some help with testing drop me a line. OK. The good news---since I have continued to work a little on this while I have more urgent things to do---is that it is absolutely _simple_ to restart from this (the original web2c)... I don't know if the road of hell is paved with good intentions; but it's clear that the software highways of hells are "organised" by GPL communities... So be prepared to the naked truth: - TeX and al. with uncompressed sources of 20 Mo. - compilation, including _cross compilation_ on any POSIX or Plan9 (APE at first, but could be native easily) in some minutes. - and installation in whatever organization you like since the installation is governed by a map describing where to put (on the target) the different pieces. (All this is already existing: it's my RISK basic Bourne shell (at the moment; rc incarnation will come) framework, which is used for KerGIS). So rendez-vous sometimes in the end of january 2010! -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] TeX for Plan 9: a point
Hello, Note (inessential at the moment): the result will be called KerTeX and not CorTeX since there is a package (one file...) called CorTeX on CTAN. But KerTeX: take care of the TeX kernel! will do... Unless one really really wants to port the current TeX distribution state, just wait: I'm sure now that I will be able to make the job. If you are only using packages of macros, you should be able to use them (``dumping'' a format) with the result. If you are using a WEB program derived from TeX (and that I don't plan to support), the conversion tools provided by KerTeX should ease a lot the task. Next news about this topic for test in January 2010 (end). This will be my "Happy new year" to the "bazaar" model... Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] TeX for Plan 9: a point
On Tue, Dec 22, 2009 at 11:44:14AM -0500, Jorden Mauro wrote: > > I know you don't plan on supporting LaTeX, but would any of these > tools help in porting that? Or is the latex program too GNUified? As far as I know, LaTeX is not supposed to be a TeX version, but a set of macros. So, as long as there are running TeX and METAFONT, one could use LaTeX. I seem to recall that ron (?) mentionned a: pdflatex, or something like that. Since the conversion: dvi -> ps will be provided, ps -> pdf can be done via gs(1). (That's what I already do, including EPS figures, for example generated by MetaPost.) Now, if they have changed so many things that LaTeX needs to change TeX or METAFONT... (One should compare the initial change file with the current ones; I would be very surprised if D. E. Knuth would be happy of the current state.) If what I'm doing is not usefull to others, well: I don't care. At least for me, I will be free from anybody; I will depend only on my own stuff "maintenable" (holding in my hand). At the present time, teTeX is orphaned, and there seems to be only TeXlive to download as a huge iso. This is simply crazy! -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] TeX for Plan 9: a point
On Tue, Dec 22, 2009 at 12:14:56PM -0500, erik quanstrom wrote: > > Since the conversion: dvi -> ps will be provided, ps -> pdf can be done > > via gs(1). (That's what I already do, including EPS figures, for example > > generated by MetaPost.) > > you'll have to fix gs to get that. gs has been crashing > here. i have to bind gs from the dump to print pdf. Mind you, I have already cleaned the Augean stables of GRASS. I'm currently (part time with some more involved stuff) cleaning the Augean stables of the distribution of TeX, so... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] TeX for Plan9: late but not dead
Hello, Just a note since I'm late vs my initial time frame schedule (I'm still busy doint something else [aka work that makes me eat]). But it is not dropped, neither dead (the matrix---the compilation framework---is already here, and I have done in december enough to know what to do and to be sure I can do). See you later... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Man pages for add-ons
Hello,
Since I can finally find some time here and there, I'm back to TeX and
al.
>From namespace(4), the man pages are supposed to be under /sys/man.
What is the canonical way for added ("opt", "pkg" ?) stuff. Letting
the user adapt his profile to bind the added stuff he wants appearing in
his namespace?
More generally, what is the policy for add-ons? Providing rc(1)
fragments to bind the added stuff?
Cheers,
--
Thierry Laronde (Alceste)
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Man pages for add-ons
On Thu, Mar 25, 2010 at 09:37:15AM -0400, erik quanstrom wrote: > > i vote for putting the binaries in /$objtype/bin or /$objtype/bin/tex. > in the latter case, it would be tex/tex or tex/mf. I'm inclined to this kind of stuff too, since it's easy to "rm -fr" if everything is simply in the same place. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Man pages for add-ons
On Thu, Mar 25, 2010 at 02:07:46PM +, Steve Simon wrote: > As far as packaging stuff up look at fgb's contrib system, > bootstratp your self into the delightful world of 3rd party packages > by typing: > > 9fs sources > /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib > contrib/gui > > man contrib will tell you about the tools and how to create > packages of your own. I will look at this. Since I use my own framework (very simple but for cross-compiling), it will probably end in a script and a map (where to put the stuff, with what name, owner and permissions) "fgb's contrib" compliant. > I have a text contrib package on there but I will remove it when you > have your updated release working. There is no urge ;) Normally, even LaTeX user's will be able to use this stuff, since it's "simply" macros --- TeX uses argv[0] to know what format to load; hence "latex" is not a program, but a hint for what "compiled" version of the macros to put in memory. But we will need to verify first that the new version delivers what it is supposed to... And the hard part is done---understanding what goes on; putting the translation stuff apart; building libraries for duplicated things etc.---, but I'm still cleaning things and going back to Knuth's books to understand what to keep and what to delete in the change files. With one or two hours per day at maximum, this will still take some weeks (I think). -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Man pages for add-ons
Well, it won't probably answer the questions of any one, but for the "package" I'm working on, these are true: 1) Compilation is a separate step (One can cross compile on a MATRIX for a distinct TARGET). 2) Sources are read-only and the compilation is done elsewhere. 3) Space requirements are low since the framework knows how to remove intermediate products on the run if needed. (I was tired to compile things that need 2 Gig to end installing 200 Mega---NetBSD comes to mind; gcc the same etc.) 4) Once compilation is done, you create a package that is simply a tarball with the stuff that needs to be installed, a script and a _map_ that tells : this thing here shall be put there, with owner: owner:group and permissions: permissions. 5) The map is generally relative to a $TARGETOPTDIR that one can set as one wants. User can also just provide another completely different map if one wants. Conclusion: it should be relatively easy for anyone to end with the stuff where one wants. There will be a default: a) If there is some kind of majority. b) If not, conform to where _I_ want to install for my own personal use ;) -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Man pages for add-ons
On Sat, Mar 27, 2010 at 06:15:17AM +0200, lu...@proxima.alt.za wrote: > > 4) Once compilation is done, you create a package that is simply a > > tarball with the stuff that needs to be installed, a script and a _map_ > > that tells : this thing here shall be put there, with owner: owner:group > > and permissions: permissions. > > Should this be a proto? Just in case you've overlooked the option, no > offence intended. The bit of lacking information that leads to false conclusions: I use my own framework (built for KerGIS) that is at the moment strictly POSIX oriented. Hence, at least as a first step---since if it's far more easy to redo the work from an old Web2c than to try to deal with the present monstruosity, it's still some work...---, the Plan9 flavor will come in an APE fashion---for the building framework and the installation framework (sh(1)), simply because it's there; for code per se, I'm tidying TeX things for C89, period.---. There are numerous things that are a problem to deal with on Unix like systems, and that are far easier on Plan9. That's probably why we are here? But I'm still using Unices, so TeX has to install on Unices and Plan9. So, what I wanted to say is: it will probably not be pure Plan9 at first (for installation); but it should be trivial to adapt to whatever one sees fit, and it will need less time to anyone to adapt than to argue about taste. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Man pages for add-ons: pax?
>From the diverse input, wouldn't it be more logical to do the following: 1) All "contrib" packages write in /$objtype/bin, /rc/bin and /sys/man (or /man, see 3). 2) It's up the user to "bind -c" in /$objtype/bin, /rc/bin and /sys/man so that written files end where he wants. Depending on who installs, so depending on the namespace, all flavors can be achieved (system wide or individual). 3) Shouldn't /man and /rc/bin be, as /bin, "empty unwritable directories, place holders", with an initial bind(1) (without "-c"; probably $objtype agnostic either, since almost all programs are supposed to exist in an $objtype flavor for man, and should not be a concern for rc) of /sys/man and (new) /sys/rc/bin there? Note: in this scheme /rc/bin is more a mean (an undirection) so that rc programs end in the correct place than something usefull at use time, since it ends probably bind'ed in /bin. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan ? (was: native install)
On Tue, Mar 30, 2010 at 01:34:12PM +0100, Steve Simon wrote: > > This way (dot-it-your-self-way) we will "only" have one-man projects. . . > > True, if anyone feels that a project is too big for them then > by all means put a shout out on the list and see if anyone there wants to > help. Everything can not always be done as a collaboration; and the main possibilities are in parallele works. This implies a kind of independance. Indeed, when there are several people working on the "same" thing, it's because the thing has been thought, is consistent (hence: thought by very few people, with one leading), so that it's an organized hierarchy of "one man" works. Take the example of TeX, METAFONT (the conversion of WEB/Pascal to something compilable on the majority of systems). When I started looking at what was going on, trying to make sense of the thing, it was not possible to be several doing this; and since I didn't know at the beginning, I couldn't obviously explain. Now I know. But it would take me all the time to explain to someone else, hence we would not be 2 doing the work, but 1 explaining without doing, and the other trying to do without having understood by doing... And the "collaborative" effort shows in the web2c result: things that are common between all the pieces written by D.E.K. are implemented with slight divergences for TeX and METAFONT, with variations in names, in parameters and so on, because some have worked on TeX, while others worked on METAFONT etc. The main task now is cleaning and deleting and having the strict minimum of code. And you can compare. Donald Knuth has done the work, the majority: the code. And a bunch of people have contributed chunks for the compilation framework. On one side, you have code (result) and consistency; on the other side, you have _inhumanity_ since you have increasing of the entropy that is disorder: order is unnatural, and is the mark of human activity. "Open source" seems very natural in this sense: the bazaar... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan ? (was: native install)
On Tue, Mar 30, 2010 at 10:07:11AM -0700, Albert Skye wrote: > > order is unnatural > > The Origins of Order: Self-Organization and Selection in Evolution > by Stuart A. Kauffman > > http://www.amazon.com/Origins-Order-Self-Organization-Selection-Evolution/dp/0195079515 order is unnatural for things lacking a conscience or a soul (in french, non animated; I don't know if the sense is correct in english). Entropy. For human societies, the less organized they are, the less human they are---the ones with the less conscience are the ones who kill, who steal, who stock exchange and so on. Do you want to live in Somalia, in the City, etc.? When it is forbidden to forbid, egoism rules, hence non-egoists die. Without a conscience, you don't know that you are and can be a part of the whole; a part of an organized whole. Nobody knows everything by his own genius, but because there are things he inherited from the previous ones; and he can go farther, by taking over (the relay). Not by sitting on the bleachers with two pounds of pop-corn. In software, when there is no more someone who understands the whole and is able to keep the whole as an entity, pieces start being taken apart, because savages want to put a graffiti on the building; the same way a dog urinate on things that emerge to tell: "it's mine". Back to software: how many developers are we _really_ relying upon the work? For myself, if I count the original ones (Unix/C, Plan9, TeX and al., CERL GRASS [ancestor of KerGIS]), this is less than 20... for something like a bit more than half a century of "computer science"... And for each piece of software I really use, there were a maximum of 3 core people involved, with one leading. And to "maintain" this, some claim there are "communities" with hundreds, if not thousands of "developers"---when for the huge majority, it will be enough to call them programmers. And there is even "software creationism": the thing exists, not when there is working code, but as soon as you have written that it will be delivered under the holy licence. I'm getting old... -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] ken-cc, 64 bits machine, and 32 bits integers
Still for TeX and al., the computation is done with tetras (32 bits),
and one of the variable thing to set is the C name for this tetra
(the identifier "integer" is used and is defined afterwards in the C
code).
"long" is guaranteed to be at least 32 bits by C89. So this could do,
but could be a little overkill:
1) If a compiler set on a 32 bits machine, "long" to be 64 bits? (I
haven't looked at the sources, but I guess it is not the case for ken-cc
suite).
2) On a 64 bits (since Charles Forsyth has done work for amd64 at least
on ken-cc, this exists), I imagine "long" is an octa (64 bits).
64 bits seems to me a bit wastefull since this won't increase TeX
precision, but will take more space. The only "plus", on 64 bits, is
that this is---I guess---the "word", the natural size, so it should be
more efficient for access.
Furthermore, in the memory_word data structure, the integer ("at
least" tetra) comes along with a glueratio (that is not a crucial
value) that should be the same size for more efficient access. IEEE
single precision is C float, and is a tetra too so does the trick on 32
bits architectures.
If "integer" is an octa (64 bits), glueratio should be a "double".
So the questions:
1) Is there any rule, at least for ken-cc, identifying C "int" with the
machine "word"? (It seems natural, but nothing is mandatory.)
2) Are tetra only _data_ programs---I don't speak about the
instructions that can be 64 bits: I speak about the data structures---
as efficient as 64 bits ones on 64 bits architectures?
/* shame */ I have only ia32 machines---and single core... and I haven't
wandered in the sources either...
--
Thierry Laronde (Alceste)
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers
On Tue, Mar 30, 2010 at 09:11:07PM +0100, Charles Forsyth wrote: > on 64-bit machines, int and long are 32 bits, > long long (vlong) is 64 bits, just as on 32-bit machines, > but pointers are 64 bits. defines uintptr > as the integer type that will hold a pointer. > u8int, u16int, u32int and u64int are used in device drivers > and elsewhere to declare values (eg, in memory-mapped > structures or protocol buffers) that must be a precise length. Thanks. As suggested by many, I will read u.h. Since I wanted to keep the code pure C89, going with "long" will do without trying to be smarter. Second option, goes POSIX/APE and use uint32_t/u32int incarnations. I think I will go the former. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers
On Tue, Mar 30, 2010 at 04:54:59PM -0400, Patrick Kelly wrote: > >"long" is guaranteed to be at least 32 bits by C89. So this could do, > >but could be a little overkill: > > >1) If a compiler set on a 32 bits machine, "long" to be 64 bits? (I > >haven't looked at the sources, but I guess it is not the case for > >ken-cc > >suite). > > >2) On a 64 bits (since Charles Forsyth has done work for amd64 at > >least > >on ken-cc, this exists), I imagine "long" is an octa (64 bits). > > Useful reading: > http://plan9.bell-labs.com/sys/doc/comp.html > http://plan9.bell-labs.com/sys/doc/compiler.html I have the printed docs (from Vita Nuova), have read them (some times ago), but probably missed the bits because I was not focused on these details then ;) -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] TeX: TRIP/TRAP passed so almost here
Hello, Just for the ones wondering what the status of the work on TeX is: METAFONT and TeX pass the (resp.) TRAP, TRIP test---this means not only mf and tex in diverse incarnations, but also a bunch of auxiliary tools. I have 4 more auxiliary to add and I will publish the first release---without dvips(1) at the moment (I'm on) and MetaPOST (will be next). This early release will allow people to verify that once they have a set of macros (say: LaTeX), they just "dump" a format, put in where TeX looks (can be set by environment variable), and "cp virtex latex", so that the program knows the dump to load by looking at argv[0]. Cu soon, -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] APE notes
Hello,
These notes about APE could be of some use to others.
Context : I'm verifying that my compilation framework, made for POSIX,
is able to work for Plan9 too (for TeX and al.: everything works on
Unix, so time to verify the whole thing on Plan9).
Note: this is not a plea to add more. ape/psh is not supposed, IMO, to
end in profile...
- some utilities are included in POSIX.2, but are not in Plan9,
including under APE : find(1), id(1), expr(1) --- of course ln(1)---.
These are just the ones I stumbled upon since they were used in my
scripts. I have find a way, so you may find one to do differently.
Note: expr(1) is typically a thing I do _not_ use, since I always feel
uncomfortable with it; but I guess I wanted to "optimize" and avoid
forking a "| sed ..." -> that just highlights indeed that an interpreter
must have regexp handling natively à la rc(1) ~.
- "grep -q" (with -s) is in SUS.v3, but Plan9 has "only" traditionnal
"grep -s". To not be eaten by a system that has "-q" and not "-s", I
ended with grep ... >/dev/null 2>&1.
- sed(1) does not support single character duplication : \{m,n\}---I
have "unrolled" the patterns, since ".+" is not supported by POSIX
sed(1) (..* does the thing in this case for example).
- I have been hit by aux/getflags I think that doesn't like too many
arguments (typically a sed(1) with a bunch of "-e s/.../.../g"). I have
simply put the rules in a temporary file, and used sed -f.
--
Thierry Laronde
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ehci/uhci interrupts
On Sat, May 03, 2014 at 07:14:34AM +0200, lu...@proxima.alt.za wrote: > > > problem found. patch appled. if a ehci controller is 64-bit capable, > > one must turn off 64-bit capabilities on all controllers before initializing > > any of them. > > Well done, Erik! Keep the posts coming, even if no one provides any > feedback; your efforts are appreciated, even if I speak only for > myself. Same here. I'm silent---because I have nothing interesting to say---but I'm listening and being ashamed of not doing enough. This simply put higher the ones who do. -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ehci/uhci interrupts
On Sun, May 04, 2014 at 07:12:10AM +0200, lu...@proxima.alt.za wrote: > > Personally, kernel pages would be a god-send Despite what one might think at first, writing documentation is not easier than writing code, and is, IMHO, harder. To write good manual pages---the Bell Labs man pages are simply great and from reading the man pages one knows that the ones who wrote the code knew what they were doing---is difficult. One can have the code done, sort of "working", without being able to explain to humans exactly why he has done the things this way or without being able to explain all he had in mind---things that subconsciously drove the implementation. I know that now, I start by "explaining" to me what I want to achieve and critize or "ask" myself the axiomatic, before indeed starting to implement---after, for the details, it is a dialog between theory and code. So now the doc and man pages appear first. Not after. And I'm verifying that the code conforms to what it was supposed to achieve (it's not as obvious as it may seem). And there is the problem of the tong. I know that when I tried to wrote directly into "english", it was a disaster. I have written the same library---in CWEB that is literate programming; code in C, explanations formated with TeX---first in english, after in french, and the result in english was nonsense for the explanations and code that worked, sort of, but had remote link (hopefully) with the explanations. Rewriten in french, both explanations and code improved, simply because I could directly map what I had in mind in words without trying to first translate i.e. betray (in italian, they says "tradutore, traditore") and because it was supposed to be read by me, first, and not to be a public monument to my supposed smartness, putting things that had nothing to do there instead on focusing on the task. So, IMHO, one embarking in writing manual pages, should start by writing in one's native tong taking the Bell Labs man pages as an example. And once there is nothing more to remove and the manual page is considered good (simplicity is the shortest way to truth), let the translation in "C" (pseudo-english) begin. I don't think too that the trafic on the list is too high to forbid, once somebody has something ready for review, to put a link and to ask for comments. -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] ehci/uhci interrupts
On Sun, May 04, 2014 at 03:29:57PM -0400, erik quanstrom wrote: > > having lived and worked in a non-english-speaking country, i think this may > vary by individual. translating back and forth was too much work and too > distracting for me. I found that if the translation is done once (when the work is more or less done), it is not a huge burden and it even helps to improve the native tong paper (ironing out fuzzy wording or discovering a simpler way to say). >additionally, i found the x:y language dictionaries to be > especially inaccurate for technical terms. FWIW, I know refer to the Elsevier's dictionary of computer science and mathematics that only gives the vocabulary in 4 languages : english, german, french, russian. It happens that my native tong is one of them. Some expressions are impossible to guess or to obtain by raw translation. -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] New /prog idea
On Sun, May 04, 2014 at 08:53:39PM -0400, erik quanstrom wrote: > > On Sun May 4 18:01:22 EDT 2014, yshu...@lynxline.com wrote: > > > > > Just idea, but seriously, why cannot do something like this: > > > > # cat /prog/new > $id > > # cat /dis/ls.dis > /prog/$id/dis > > # echo "/" > /prog/$id/cwd > > # echo «Running» > /prog/$id/status > > > > Not to do it which echo/cat, but to have remote access to /prog/new > > so that's an interesting idea. i've toyed with the idea of having > a mount driver analog for system calls, but got tripped up on > the details, and the lack of a specific need. The Bell Labs paper about plan9 talks about metaphors that can be abused: "Nonetheless, it is possible to push the idea of file-base computing too far." This the "Discussion" at the end of the paper... Playing with the idea and thinking about the implementation is probably a good way to understand the paper... -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] [GSOC] fast kernel compile
On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote: > On 6 May 2014 03:19, Charles Forsyth wrote: > > Of course, that's balanced > by browsers now easily rivalling the kernels you mention for complexity and > certainly size, with their brutalist programming architectures. And it is even not a problem reserved to Plan9. On a NetBSD, I tried to compile chrome. The PC had even not enough _memory_ to link the thing... -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] [GSOC] fast kernel compile
On Tue, May 06, 2014 at 11:39:03AM +0200, tlaro...@polynum.com wrote: > > On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote: > > On 6 May 2014 03:19, Charles Forsyth wrote: > > > > Of course, that's balanced > > by browsers now easily rivalling the kernels you mention for complexity and > > certainly size, with their brutalist programming architectures. > > And it is even not a problem reserved to Plan9. To explain in my answer the link with the Plan9: browsers are so huge beast nowadays, that the lack of a "modern" browser on Plan9 will rapidly become a problem for others than Plan9 since these things are so huge and complex and need so many pieces than even on Unix like systems, one may not be even able to link the thing. -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 Sources Repository
On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote: > > Plan9 in general doesn't follow the Bazaar model ( the current usual > way of doing things ). > The Bazaar model is the one for not doing or undoing. Small is beautiful. The attraction for Plan9 is its consistency and size. As far as I'm concerned, the current organization is not a drawback from contributing more---time is. Another organization will not offer, for me, more opportunity to contribute. When I have something to contribute (and for now, this is only user level kerTeX), nothing impeds me from doing. This is for user level. For kernel, the problems may be more involved. But clearly, the number of persons able to contribute is far more limited. And consistency shall be the primary aim. So an organization good for a "small team" is an organization good for kernel level. My 1 cent, -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Compiler Message
On Mon, Jul 21, 2014 at 12:55:44PM +1000, Shane Morris wrote: > > clang: error: unknown argument: '-mno-fused-madd' > [-Wunused-command-line-argument-hard-error-in-future] > clang: note: this will be a hard error (cannot be downgraded to a warning) > in the future Apparently the "future hard error" is treated as an error. It looks like clang does not understand the gcc argument '-mno-fused-madd'. Only the developers of Inferno would know if multiply-add for float caveat is really a requisite for Inferno. So look if there is the equivalent in clang, and convert the argument; or suppress it where it is defined in the mkfiles (perhaps it is necessary for gcc, doing "things", and not necessary with another compiler, so the compiled program will not exhibit any problem). HTH -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] OT: What linux has become
On Wed, Aug 13, 2014 at 10:02:46AM +0200, dante wrote:
>
>[...]
> I also have the impression that the trend set by the original Unix
> architecture (small, one-job components, generic interfaces)
> is nowadays replaced in many areas with integrated solutions
> ("frameworks") that provide non-separable components
> and sometimes redundant interfaces.
>
>[...]
> One reason why I try to take what I can from Plan9 is that I profoundly
> mistrust systems that I cannot understand due to their size/bloat.
>
And the more "curious" (perhaps not...) is that the "trend" is on
"security", while I fail to see how there can be any security when the
software is not "maintenable" (from french : "tenir en main" i.e. be
able to direct and keep in one's hand).
There is a Borges short story about a library where one supposes
that every text possible is kept, hence if "the" solution about
the "why" is able to be expressed, "the" solution is for sure among
the books. Problem : it is not sure that one reading it will for sure
understand that this is "the" solution; and the time to read
everything in order to find it exceeds largely one's life time.
Consequence : this "ideal" solution is absolutely useless. Software
nowadays seems like this : the time it takes to install and to
start is time lost for working with (and this may amount to some
time); the time to understand the thing or to debug it, is larger
than an average life time, and is not possible for an average human.
Security by threat (for example in "free" software): "one" can look at
the code. Yes... Try to find a needle in a hay stack... And these beasts
are Medusa: one look at the sources, and you're changed to stone by
fear.
There was also a comical story from a past artist about the
"improvements". The propaganda had made advertising for the "perfect"
washing powder. Problem: when the next one came out, it begun
difficult to explain that it was more than the previous perfection,
unless the very same vendor admitted the swindle... So the advertising
was explaining that by using the "new" improved washing powder, it
was even able to wash as perfectly as the old one, even if one made
knots with the clothes to "hide" the dirt inside (probably because
the "old" washing powder was using its big blue eyes to see the
dirt, while the "new" was using its nose). Conclusion: one had the
same result as before with the "improved" version, except it took
time to make the supplementary knots...and a week to try to undo
them after they spent some hours in the water...
Are there still human beings believing that "progress" is a function
of chronology: the newer, the better?
--
Thierry Laronde
http://www.kergis.com/
http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Many bugs in eqn(1)
On Wed, Aug 13, 2014 at 03:30:37AM -0700, c...@9.squish.org wrote: > > sorry, i am unable to help with this specific problem. i only > use the ms macros and use tex for anything more. > Does anyone know if there has been any effort to use TeX and al. for the system typesetting i.e. the manpages and docs? (Translation of the troff macros to TeX ones etc.---not to mention that for TeX (kerTeX), it needs to be converted for utf-8 input; that's on my TODO list but I need to finish the rewrite of the T1 lib for dvips(1) first, and the display for METAFONT.) -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Many bugs in eqn(1)
On Wed, Aug 13, 2014 at 02:22:00PM +0200, Carsten Kunze wrote: > > > Is this really necessary for the system documentation? AFAIK P9 nroff/troff > can handle utf-8. If there are problems with *roff they should be solved. > *roff is a Bell Labs documentation system--it should be used for P9--IMO. IMO, the advantages are multiple: 1) TeX is a complete system: not only the layout engine, but the means to draw the fonts. METAFONT is also a rasterizer engine. This means that the system can be self-sufficient allowing to render the result without resorting to huge external PS dependencies; 2) TeX programs (for the D.E.K. parts) are fully documented and fully debugged. Before, I thought that using Pascal as the programming language was a problem (I never managed to like Pascal). But having work for kerTeX with the WEB programs, I understand now that this is not really Pascal, but some Algol. The translation from _this_ Pascal to C is under control, so the programming language is not a problem after all and probably prevents lots of people from tempering with it: TeX is stable; 3) The "typesetting" system is not my aim. My aim is to use it as a mean for producing documentation about something else. Having several languages to learn for, in fact, doing the same thing while it has been recognized that for math, TeX is an improvement, is suboptimal; 4) TeX and al. and the original Web-to-C were not bundled under GPL. Now, with kerTeX, the bundle is not anymore with GPL (and for systems, whether Plan9 or the *BSD, since what I did use was under public licence, and what is added is mine, I could re-licence my contributions to the very licence of the systems). Other troff implementations are whether under GPL, or the improvements were made taking from TeX (Heirloom); 5) With kerTeX, we are back with the needle only and not the whole hay stack and the whole core thing is really, really small. Including fonts. -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Many bugs in eqn(1)
On Wed, Aug 13, 2014 at 03:13:38PM +0200, Rudolf Sykora wrote: > > Just to be sure. I don't mean readability of documents to be typeset. > I mean the source code of the whole system. I.e., in the case of LaTeX, > the readability/understanding/hackability of the macros' definitions. > And this links to another thread: the base plainTeX system, with fonts, is 8Mo; with the AMS this may reach 16Mo. With LaTeX and al. (I don't use, but others do and I need to test somewhat), the whole thing reach 250Mo. PlainTeX is not a litteracy exercice, sure, but is documented and small. And riding piggyback on plainTeX, I'm mainly covering my needs. And I decided to use plainTeX whan I saw that there were less pages, written by the author: D.E. Knuth to explain fully how to use and program TeX, than pages trying partly to explain how to use LaTeX without attempting to explain how TeX was working underneath. And if one doesn't understand TeX, one is unlikely to even have a clue about why the LaTeX macros do not do what one supposed them to do... -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] The developers of Plan9 think there was no point in coding in binary code three years ago as they did or make the Riga Technical University and University of Latvia?
On Wed, Aug 13, 2014 at 11:06:23AM -0400, erik quanstrom wrote: > > > > I say this because about three years ago the Riga Technical University > > > and University of Latvia continued teaching coding in binary code, ie, > > > machine language. > > that's great! very vew people understand how any machine really works. > it might not be something one can readily apply to another system, but it > will give you insights that can be reused in a lot of situation. D.E. Knuth has kept a machine language (MIX, and MMIX for the new version) to explain the algorithm in TAOCP. And there are some interviews of him explaining why. Since even "schools" should teach the principles and not the particular means (why and what has to be done and not how to do it precisely with the software or language du jour), it is not bad per se. If a real language has to be used, I don't understand why C seemed to have never caught up. Because it is high level for control and expression, and low level, near the machine, so it seems the best compromise. I really started to program a minimum correctly once I understood at least roughly how the machine and the system were working. Before... -- Thierry Laronde http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Factotum vs SASL
On Mon, Dec 01, 2014 at 09:00:46AM +0200, lu...@proxima.alt.za wrote: > > The guy in front of the console should authenticate as a normal user > > and then only be allowed to access his own environment (no direct > > control over hw, etc). > > The guy is not in front of the "console", he has physical and > therefore unrestricted access to all the resources in the terminal. But, IMHO, this is precisely the difference between Unix and Plan9. In Unix, the console or X11 are dumb terminals. There are only no-computing-capabilities devices to interact; they are no terminals as in Plan9. This is why X11 has put the network in the wrong place. The X11 "server" is just a remote graphic card; it is mimicking with graphical devices what has been done with text devices (tty). In X11, all processing, including handling the graphical menus, the display, is done by the client. While on Plan9, the processing of the data can be done in a CPU tightly coupled with a file server, while the handling of what is displayed (menus for example) can be done on the terminal. In Unix, consoles and X display are just remote devices to interact, while the processing node they are connected to can be out of reach. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Gsoc: Plan9 not the only one
For info, NetBSD neither has been selected as a mentoring organization this year. I think it's fair for Google to devote help for softwares that do have huge problems :-^ that can not be addressed by a single person, but only circumvented by mass mobilization... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] origins of configure
On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@skeeve.com wrote: > So, the history is more than this. > > Larry Wall's Configure (capital C) for rn and Perl was the first step > at a shell script to examine system features and generate a config.h. Using a shell script to generate commands to compile on diverging Unices was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this predates Perl and so on. I guess it is not the only example. >[...] > Autoconf was designed to solve real portability problems. There are two problems with the autotools stuff: 1) Features are fixed for OSes, but the configuring is done other and other again for every program. What a system offers shall be known; and what the developers require shall be known too. Autotools was designed in a world where neither the OS nor the developers exactly know what they use; 2) Cross-compilation was not in mind, with some features tested by compiling and running programs. The result is that the majority of software built with autotools needs to be compiled natively (even installed on an equal system since the layout is searched on the building node); 3) To try to understand what's going on with several steps and huge configs is out of reach. Rule: when it takes less time to build a solution from scratch than to try to understand how to _use_ an existing solution (not to mention understand), this solution has to be safely stored in /dev/null. Note: I have put my money where my mouth is : I have built such a solution: the one publicly used with kerTeX---but it is a side effect, it was not meant to be released. And it solves the 1) and 2) and solves too the space problem: when an object is not any longer necessary, it can be automatically removed, limiting the space needed to compile to the bare minimum. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] p9p sed vs linux sed
On Wed, Aug 12, 2015 at 09:57:18AM +0200, Rudolf Sykora wrote: > On 12 August 2015 at 09:48, Ingo Krabbe wrote: > > > Actually sed is a line based command and should add a newline, imho. > > I don't think it should add anything. For itself it should be able to count > newlines (because of the possible use of addresses), but otherwise it > should not do anything extra (it should be possible to pipe through > two seds, for instance). > >From the POSIX description (used here as some reference), when a line is entered in the pattern space, the trailing new line is discarded. When the pattern space is written to stdout it seems that implicitely the new line is restored---the POSIX description says that the input shall be a text file; and ISTR that with an editor, a newline is entered to the last line because a text file is considered to be an array of newline terminated lines. This means that it is a grey zone and depends on things that are not all explicitely stated and that the p9 sed(1) is not, from the/some specification, at fault. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Undefined Behaviour in C
On Thu, Nov 26, 2015 at 06:22:45AM -0500, Brantley Coile wrote: > > I thought the same thing, using ~0 for nil, but realized two things. First, > that's a valid address on the PDP11 where the convention developed. It's the > unibus space. Second, ~0 + member offest is still in page zero. > Plus, in C, 0 is used as a truth value for false... As long as no logical type was added but values used as logical values, the choice of 0 for "false" address is "logical" enough... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Compiling ken-cc on Linux
On Fri, Nov 27, 2015 at 09:13:20AM +0100, Giacomo Tesio wrote: > > I know nothing about compilers, but actually gcc and clang dimension and > complexity is astonishing. It's not astonishing: it's research. They want to prove that a black hole does exist. So they write a "model", a software implementation of black holes that is, indeed, able to absorb every bit of RAM, every block of disk, every CPU cycle so that whatever is put in a computer, nothing can ever go out. And the thing finally collapses due to its very size: so big that no one is able to understand and correct it. Then it is called: "standard", a de facto no varietur, not because it is perfect not to mention useful, but because it is impossible to evolve. It's a kind of success (though there are a lot of competing implementations of software black holes, improving almost endlessly: less and less signal, more and more noise). -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Compiling ken-cc on Linux
On Fri, Nov 27, 2015 at 03:07:30PM +0100, Giacomo Tesio wrote: > > Funny, but actually I was wondering if there is any subtle issue in the > standards of the C language that makes it somehow hard to implement. I guess it depends on what is the "standard". The naked C language is (was) simple. The guaranteed routines were something else: the C library---contrary to Pascal, for example, where some routines were part of the language. That's the way I understand Charles' irony: it seems difficult to find a more simple (and efficient) language as C. There are problem with standards but there are far more problems with people that do not refer to standards and do not know what they use. Using Plan9' APE is a good way, for example, to ensure that one is only using POSIX. Yes, it is not up-to-date since POSIX evolves; but failing to compile with APE is generally not due to missing pieces in APE but to fuzzy use of things outside POSIX in the program one wants to compile. BTW this was already the case when the Plan9 paper about APE was written. But it's getting worse. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Compiling ken-cc on Linux
On Sun, Nov 29, 2015 at 07:57:58AM +0200, lu...@proxima.alt.za wrote: > > I remember using AutoCad 2.6 on an 8086 with a floating point > accelerator and being impressed by the speed of its 3D rendering. I > have no idea how AutoCad behaves these days, but faster rendering > would imply finishing before it even started. So where is the real > improvement? > You could have been impressed with Microstation (originally from InterGraph) doing everything in scaled integers (it was clear it came from Unix world too by several features, like regexp) so using only the CPU. It run smoothly on 386 with DOS and DOS extender. Once they "ported" it to Windows 95 and NT, we waited years for the hardware to be able to give back the performance we had with "poorer" hardware and OS. It almost took 10 years if I'm not mistaken... And I hear that progress is "continuous". In another world probably... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Rio: possibility to forbid resizing a window?
Hello, After a long delay, I'm working back on kerTeX and I'm adding the display for METAFONT (it's more interesting than one could think, since METAFONT is the program mainly ignored while being a drawing program and a rasterizer engine...). But once the size of the root window for display (the user can subdivise this root window from METAFONT) is given and the window created, the dimension should not be altered. There is the possibility, in X11, to give the window manager hints and to disallow resizing the window. Is there such possibility with rio? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Rio: possibility to forbid resizing a window?
On Thu, Dec 31, 2015 at 07:33:42PM +, Skip Tavakkolian wrote: > I wonder if it would work if wctl was chmod to read-only? Might break other > things. Hum... Thanks for the suggestion, but I imagine that rio, when a user resizes with the mouse a window, does not send commands, pixel by pixel, to the window for resizing but call the very code called for the command passed via wctl? Actually, I will not use neither wctl, nor cons or mouse, since the window is just for the graphical display. I will not fork either a process and will just draw using the $wsys hierachy (since the namespace is the one of METAFONT and the particular window files in the namespace will be the ones of the shell where mf was called). > > On Thu, 31 Dec 2015, 9:08 a.m. wrote: > > > Hello, > > > > After a long delay, I'm working back on kerTeX and I'm adding the > > display for METAFONT (it's more interesting than one could think, since > > METAFONT is the program mainly ignored while being a drawing program > > and a rasterizer engine...). > > > > But once the size of the root window for display (the user can subdivise > > this root window from METAFONT) is given and the window created, the > > dimension should not be altered. > > > > There is the possibility, in X11, to give the window manager hints and > > to disallow resizing the window. > > > > Is there such possibility with rio? > > > > TIA > > -- > > Thierry Laronde > > http://www.kergis.com/ > > http://www.arts-po.fr/ > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > > > -- > > Thierry Laronde > > http://www.kergis.com/ > > http://www.arts-po.fr/ > > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > > > -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Install problem: disks not listed
Hello (and best wishes to all for 2016!), I have a new node and I'm trying to install Plan9 on it (it is a multiboot node, with already NetBSD and Windows). When booting (from Bell Labs' iso), the disks are found as sdE[12], the CD driver as sdE0 that are all on SATA. But when going to partdisk, the disks are not listed and partdisk fails. "Somewhere" before the call to partdisk, the mount of the disks failed. Does somebody have a clue as to where to find the culprit or can somebody give the sequence of commands launched when selecting to install from the CD so as to be able to find the hiatus? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Rio: possibility to forbid resizing a window?
On Fri, Jan 01, 2016 at 02:58:07PM -0800, erik quanstrom wrote: > > Is there such possibility with rio? > > yes, this is implemented by games/sudoku. just refuse to resize. > Thanks. I will give a look to the code. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] Install: root file system
Hello, As explained in a previous message, I try to install Plan9 on a new node (previous one defunct). I have tried the usb Bell Labs and 9 atom flavours, and none works on my node. The Bell Labs iso works (I mean it boots and the install starts) but 9pcflop doesn't recognize my disks (while 9load lists them correctly). So I'm back to what I had already done: I sketch a Plan9 partition from NetBSD, setting a bootable FAT and populate it. 9pcdisk recognizes my disk but there is the problem of the root file system---an initial one, so that I can make the install from 9pcdisk and not 9pcflop. I have populated the 9fat with what is indicated in the proto. But there are binaries not in the iso image (bargraph, tailfsrv and a few others). So I have extracted the embedded root.bz2 from 9pcflop (found in bootdisk.img on the ISO) with the help of grep, od (because there are nulls to have the correct offset) and dd. The problem is that this is not only bzip2'ed, but previously bflz'ed. I can even not add the bflz binary to the FAT, since there is no such binary on the ISO. The questions are the following: 1) Is it possible to specify as bootargs the 9fat as the root filesystem? If yes, what is the plan9.ini syntax (I tried local!#S/sdE2/9fat, but this is not it...); 2) Is it possible to give the root.bz2 as a filesystem to a vanilla kernel (here 9pcdisk)? Does it have the code to load it in memory, or can I cat 9pcdisk with the root.bz2 (with the sentry "bzfilesystem") like what is done with 9pcflop? 3) Can such a root file be served, if nothing local work, as a root file system for a DHCP request? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Install problem: disks not listed
On Fri, Jan 01, 2016 at 01:25:20PM +0100, tlaro...@polynum.com wrote: > > I have a new node and I'm trying to install Plan9 on it (it is a > multiboot node, with already NetBSD and Windows). > > When booting (from Bell Labs' iso), the disks are found as sdE[12], the > CD driver as sdE0 that are all on SATA. > Replying to myself: sdiahci is commented out in pcflop, hence the AHCI SATA are inaccessible from 9pcflop. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Install: root file system
On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote: > i'm not sure what the root cause of your problem is, I'm now suspecting that the underlying problem is that a 9fat is a dos, but that is a special dos: part of a plan9 slice, so whether kfs or fossil supplementary partitions are expected. I have changed the MBR identifier to big FAT16 (6) and in this case 9load doesn't find a Plan9 slice and ask for a kernel, the sdE2!dos!9pcdisk.gz is OK (but it panics after since it doesn't ask for a plan9.ini). > due to not enough data, > but it does remind me of a limitation that has been bugging me. > > to boot from usb cleanly, i added a bit to the boot process that creates a > loopback > sd device /dev/sdu0 that points to the usb disk device. i've been booting my > auth > server this way for some time. > The idea is interesting. Another idea/question appeared to me: could it be possible to add a device identifier # to the booting device or publish it in the name space under /boot? Corollary: when an embedded bzfilesystem ships with the kernel, is there an device identifier that allows to access it? (From a cursory look at the proto, it seems that the file is published under /boot, but since the 9pcflop has no the sdiahci drivers, I try to simply catenate the 9pccd---or 9pcdisk FWIW---with the root.bz2 extracted, guessing that this is 9load task to arrange the loading, but I didn't find a way to access it directly from kernel hierarchy, since it is not visible in namespace). > it seems to me that i really screwed this up. what i really want is a sd > device > that always points to the boot drive, the one bios refers to as 0x80. > givem this, one can then put something like "bootargs=local!#S/sdB0/fs" > in plan9.ini. this will allow the 9atom usb install image to run off any > bootable > media (for which we have drivers). > :-) This has always been the "pleasure" of the bootstrapping procedure in the PC world. If I understand correctly, it is normal on other architectures to pass through the bios to access some hardware. With the PC, there is the limitation of the interface and, essentially, the real mode problem. But it is indeed a bit frustating to see devices accessed at booting (hurrah! my hardware is recognized!) and suddenly not recognized (when the BIOS is not used anymore and the kernel is on is own without the drivers)... Related question (for whoever has an answer): unfortunately my node has only a PS2 combo, so that I could, theoretically, have whether a PS2 mouse xor a PS2 keyboard. In fact, when the mouse and keyboard are both connected via USB, 9pcflop has no problem: I have keyboard and mouse (BIOS emulating PS2 interfaces). If I use 9pccd or 9pcdisk, I loose the keyboard (and don't have the mouse if it is connected to USB). So it seems I could have a running Plan9 (it works for mouse and keyboard attached via usb with 9pcflop, but 9pcflop doesn't recognize the SATA/AHCI disks; 9pccd or 9pcdisk recognize the sdiahci, but don't recognize the usb mouse and keyboard; I hope a synthesis is possible with the "best" of all worlds)? But what does the usb attachment work with 9pcflop for mouse and keyboard and doesn't work for the others---perhaps because 9pcflop doesn't recognize usb and hence fall back to a PS2 BIOS provided interface? > so, i'm preparing a patch that will present the boot device as /dev/sdB0 > regardless > of what underlying disk driver or protocol is being used. here's the output > from > my test machine. it's been booted over the network, but even so bios has > assigned > a 0x80 drive, and it's been found and configured: > > >>sdB loop #S/sdF0/data > sdE ahci ahci port 0xfe00fb538000 pci 0.17.4: 64a ncq alp led clo > pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 8002 > isr 0 pi f 0-3 ver 10300 > sdF ahci ahci port 0xfe00fb532000 pci 0.31.2: 64a ncq alp led clo > pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 8002 > isr 0 pi 3f 0-5 ver 10300 > sdN nvme port 0xfe00fb41 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 > stride 1 to 2 fatal 0 > sdO nvme port 0xfe00fb30 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 > stride 1 to 3 fatal 0 > That's interesting! For the mean time, I guess I will have to put an unix to serve 9P for a locally loaded kernel---but I will have to adapt the inst/ scripts since some programs are in the image embedded for the installation but are not present on the CDROM. And I will have to find a way to be able to use both mouse and keyboard, or it will be a no-go. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Install: root file system
On Mon, Jan 11, 2016 at 06:06:57PM -0200, Iruatã Souza wrote: > Never tried it, but you could try installing 9front, then your > distribution of choice atop of that. If nothing else works, I will fall back to a kernel loaded locally from the sketched "by hand" plan9 partition (indeed the 9FAT at the very beginning) but accessing a network root filesystem served by a NetBSD node serving 9P. But I investigate other tracks---see below. > > On Sun, Jan 3, 2016 at 8:06 AM, wrote: > > On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote: > >> i'm not sure what the root cause of your problem is, > > > > I'm now suspecting that the underlying problem is that a 9fat is a dos, > > but that is a special dos: part of a plan9 slice, so whether kfs or > > fossil supplementary partitions are expected. If I'm not mistaken, the man page about kfs is misleading. It says that indeed what is not fossil is treated as "kfs", but that "kfs" handles cd9660 or dos too. If I understand correctly, this is not true. This is 9660srv or dossrv or bzfl programs that are copied as "kfs" in the special installation kernel root according to the type of the root filesystem to read. And since in the installation kernels there is no kernel with a dossrv masquerading as "kfs", it fails (the 9pcflop doesn't support sdiahci, and this is _the_ problem; so I can't use the embedded bzfl root image since only 9pcflop has the "kfs" to read it; 9pccd supports sdiahci but it expects an ISO filesystem---and the "live" cd is not very alive; I don't know if this is via emulation, but everything is incredibly slow even to try to bootstrap the installation by entering commands in the CD live plan9. Note to others: I have only a PS2 keyboard/mouse combo, and other serials are all USB. Disabling via plan9.ini the USB, even if attached as USB devices, the mouse and keyboard appear (I guess by some BIOS emulation). If USB is on, I have no mouse and no keyboard, or only one of the twoi: the one connected to the PS2 combo. For root filesystem experiments, I have even tried to create a "kfs" partition in the plan9 slice, embedding in my case a cd9660 filesystem hoping that giving this as the rootfilesystem the 9660srv masquerading as kfs in the 9pccd will be able to read it. But boot fails with a "/ incorrect format" that I'm unable to understand at the moment (but can be caused by the specification given as bootargs in plan9.ini; I will try to investigate a little further if I have some time). -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] kerTeX update; but please wait for rio...
Hello, I have updated kerTeX with the latest sources from Donald E. Knuth (and the latest version of the AMS fonts). Mainly (I have only resumed working on it after months of ENOTIME), I wanted to add METAFONT online graphics output (the rendering on screen of METAFONT drawing) and have done it for X11 2D system. (Why? First, because it allows to use the totality of what is described in the METAFONTbook; Second, because it shows that METAFONT is not only a interpreter/compiler for a drawing language but a _rasterizer_. Smaller than gs if you see what I mean...) The next 2D interface will be Plan9/rio (I will finish with "native" compilation on Windows and Windows/GDI). So please wait a little, time for me to restore a plan9 environment and to put the rio interface for METAFONT. It should not take long... if I find the correct slot of free time... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] bad character set for rune...
Hello, I'm on the way to install Plan9 on a new node. Since with the CDROM or the (different flavors of) USB images, it doesn't work, I'm "bootstrapping" by hand. I have made, from an external OS (NetBSD), a plan9 partition with the initial 9fat configured and populated in order to be able to boot boot. Since, so far, I have been unable to convince the 9pccd kernel to read an iso file of the root file system put whether in the 9fat or in plan9 partition in a "fs" subpartition, I'm now serving a root filesystem via 9P2000, from another node. Well, it works, but when launching the installation (I have copied the various scripts so that they are in the served /), I have the message, continuously repeated: bad character set for rune 0x in /lib/font/bit/lucm/unicode.9.font since it is the font loaded for rio. (The rio windows are blank, the message is on the "console".) Has anybody any clue about what is causing this? Can a program needed to read/decompress/whatever the font be missing (I have tried to put on the root only what is needed)? If yes, what is this program? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] bad character set for rune...
On Wed, Feb 10, 2016 at 10:40:21PM +0100, tlaro...@polynum.com wrote: > > Well, it works, but when launching the installation (I have copied the > various scripts so that they are in the served /), I have the message, > continuously repeated: > > bad character set for rune 0x in /lib/font/bit/lucm/unicode.9.font > > since it is the font loaded for rio. (The rio windows are blank, the > message is on the "console".) > Replying to myself: because I had copied the unicode.9.font but not the other components (files) or subfonts (? Is this the correct term). Once done, it works... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] plan9.ini: ipconfig and bootargs
Hello, When trying to re-install a Plan9 on a new node, being unable, with the kernel compiled present on the CDROM image, to access a FAT or an iso image of a root file system, I went to a combination of a minimal sketch of a plan9 slice, with a 9fat made "by hand" (from an already installed other OS---here NetBSD) and access at boot time a remote root filesystem, for the installation, serves by another Unix node serving 9P2000. The surprise is with the bootargs, in plan9.ini, supposed to configure the network for the node, in order to access a remote root filesystem, as in: fs=192.168.1.3 # auth not used auth=192.168.1.3 bootargs=tcp!-g 192.168.1.1 gbe 192.168.1.2 255.255.255.0 what is after the '!' being supposed to be args to ip/ipconfig. The problem is that the gateway is taken as _another_ ip address for the interface! and that the mask is taken as the "node" serving the root filesystem! "fs" not being taken into account. Only: bootargs=tcp!gbe 192.168.1.2 works... Is the ip/ipconfig embedded in boot reduced as to not take all the options? (I don't need them; but the wiki page is the wrong; and I wonder if I'm doing something wrong or if there is indeed something changed since the page was written...) -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] plan9.ini: ipconfig and bootargs
Hello Erik, On Mon, Feb 15, 2016 at 07:41:37AM -0800, erik quanstrom wrote: > On Sun Feb 14 08:30:20 PST 2016, tlaro...@polynum.com wrote: > > Hello, > > > > When trying to re-install a Plan9 on a new node, being unable, with the > > kernel compiled present on the CDROM image, to access a FAT or an iso > > image of a root file system, I went to a combination of a minimal sketch > > of a plan9 slice, with a 9fat made "by hand" (from an already installed > > other OS---here NetBSD) and access at boot time a remote root > > filesystem, for the installation, serves by another Unix node serving > > 9P2000. > > > > The surprise is with the bootargs, in plan9.ini, supposed to configure > > the network for the node, in order to access a remote root filesystem, > > as in: > > > > fs=192.168.1.3 > > # auth not used > > auth=192.168.1.3 > > bootargs=tcp!-g 192.168.1.1 gbe 192.168.1.2 255.255.255.0 > > > > what is after the '!' being supposed to be args to ip/ipconfig. > > here's what i have on my cpu server > > nobootprompt=il -g 10.1.10.1 ether /net/ether0 10.1.1.1 /112 > > nobootprompt is equivalent to bootargs Yep (but since I was testing, I wanted the prompt and the ability to change with bootargs). But what kernel do you boot? Because, reading the various inst/* rc scripts, I gather that 9pcdisk is perhaps an "old" kernel (9pcf is used instead now) and this is perhaps I used this 9pcdisk kernel that the whole string is not correctly interpreted... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] rtl8169 gbe slow
Hello, I have finally managed to install plan9 on my new workstation. By putting back the keyboard on the PS2 connector, I have solved some unfelicities (with the USB->legacy emulation, the keyboard switched every other typing to UPPERCASE...). The mouse, still USB connected and hence "emulated" by the BIOS, does not react very gracefully but I will see if I can play with the acceleration and the resolution to have a better terminal. (Or if I manage to find a long enough cable to have a COM slot back since there is the bare connector on the motherboard; in this case I will go back to a com mouse and will be able to probe USB for other devices---external disks.) One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but when testing the compilation of kerTeX (it has been fixed: it works for the last release; rio to come for METAFONT), the throughput with hget is abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have plenty of RAM and the blocks cache for fossil is set to 3000---it could be obviously higher). Setting the mtu to jumbo packet does not help. Is there something to tune or is it simply that the chip is not well supported? TIA -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] NetSurf (browser) and Duktape (javascript)
NetSurf (http://www.netsurf-browser.org/) is a browser written in C. And Duktape is a javascript engine written in C too. Has anybody given them a look? -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] NetSurf (browser) and Duktape (javascript)
On Thu, Feb 18, 2016 at 08:41:27PM +0100, Jens Staal wrote: > 2016-02-18 15:26 GMT+01:00 : > > > NetSurf (http://www.netsurf-browser.org/) is a browser written in C. And > > Duktape is a javascript engine written in C too. > > > > Has anybody given them a look? > > > > Several NetSurf libraries (used to) build fine under APE. I probably should > try again sometime and upload to the 9front-ports project. > > What would be really cool is if the LibNSFB (netsurf framebuffer > abstraction library) would be ported to Plan9, since this would mean that > it might be possible to run a NetSurf port natively (if all the other parts > compile well) I have already too many things on the stack---and late. But as for TeX, I wanted to do the stuff years and years ago and never done anything significative untill I finally got angry about my written work in danger, so I've finally done it. So if nobody beats me, I may do it. Some day. But it's probably not in the near future. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] NetSurf (browser) and Duktape (javascript)
On Fri, Feb 19, 2016 at 01:17:12AM +0100, Aram H?v?rneanu wrote: > What problem would this solve, it's not like netsurf can display any > useful web page that mothra can't display. NetSurf will incorporate Duktape javascript engine. Does Mothra have javascript? -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] rtl8169 gbe slow
On Thu, Feb 18, 2016 at 05:22:42AM -0800, erik quanstrom wrote: > the 8169 driver is pretty fast. I've measured it at more than 500mbps. > it sounds like something else is misbehaving. what does > /dev/irqstat say. I bet something is stuck. > Is /dev/irqstat a lapsus? Here are /dev/irqalloc and /net/ether0/ifstats: 3 0 debugpt 7 0 mathemu 8 0 doublefault 9 0 mathover 14 0 fault386 15 0 unexpected 16 0 matherror 32 0 clock 33 1 kbd 35 3 sdE (iahci) 38 6 floppy 39 7 lpt 42 10 ether0 44 12 kbdaux ifstats: TxOk: 4483 RxOk: 7520 TxEr: 0 RxEr: 0 MissPkt: 0 FAE: 0 Tx1Col: 0 TxMCol: 0 RxOkPh: 7482 RxOkBrd: 28 RxOkMu: 10 TxAbt: 0 TxUndrn: 0 txdu: 0 tcpf: 0 udpf: 0 ipf: 0 fovf: 0 ierrs: 0 rer: 0 rdu: 0 punlc: 0 fovw: 0 tcr: 0x2f200700 rcr: 0xe70e multicast: 10 phy:1000 796d 001c c914 01e1 c5e1 000d 2801 4e2e 0300 3800 3000 01ee ac9c 8040 0006 4100 2100 8c00 0040 0106 217c 8fbc 0123 rcv descrs processed at once: highwater 2/255 curr 1 hitmax 0 xmit descr queue len: highwater 0/31 curr 0 hitmax 0 Note: _this_ card is a PCIe supplementary one. There is another rtl embedded in the motherboard that Plan9 does not recognize: rtl8169: unknown mac 8168 4c00 oui 0x732 phyno 1, macv = 0x2c00 phyv = 0x0004 #l0: rtl8169: 1Gbps port 0xC000 irq 10: e8de2701f455 I have tried by disabling the embedded ether controller, the result is the same. Another kernel message for what is worth (since I don't know what it means, I don't know if it's relevant): i8042: fe returned to the ea command -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] NetSurf (browser) and Duktape (javascript)
On Fri, Feb 19, 2016 at 02:00:47PM +0100, Kenny Lasse Hoff Levinsen wrote: > Styling/proper rendering might be more interesting than JS. > Unfortunately, today, there are a number of sites that require javascript. I don't speak about overloaded media sites. But for example bank or even governemental sites. It is unfortunate to have, for some common tasks, the need of "something else" (and due to the size and complexity of Mozilla and Chrome, "something else" can be a pretty restrictive choice). If I'm not mistaken, Russ Cox says somewhere that he was happy working under Plan9 but that he ported the Plan9 utilities to other systems when he realized there was no hope that someday Mozilla will run on Plan9... So he still uses Plan9 utilities, but not under Plan9... -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] rtl8169 gbe slow
On Fri, Feb 19, 2016 at 07:13:23AM -0800, erik quanstrom wrote: > > > TxOk: 4483 > > RxOk: 7520 > [..] > > xmit descr queue len: highwater 0/31 curr 0 hitmax 0 > > this doesn't look like very much traffic. how did you test? are you using > the latest tcp? what is the ping latency? older labs kernels did a poor job > with moderate latency, and any packet loss. newer versions should be ok, > but i haven't tested myself. > sending 32 64 byte messages 1000 ms apart to icmp!192.168.1.1!1 0: rtt 310 µs, avg rtt 310 µs, ttl = 64 1: rtt 314 µs, avg rtt 312 µs, ttl = 64 2: rtt 295 µs, avg rtt 306 µs, ttl = 64 3: rtt 269 µs, avg rtt 297 µs, ttl = 64 4: rtt 325 µs, avg rtt 302 µs, ttl = 64 5: rtt 267 µs, avg rtt 296 µs, ttl = 64 6: rtt 279 µs, avg rtt 294 µs, ttl = 64 7: rtt 270 µs, avg rtt 291 µs, ttl = 64 8: rtt 272 µs, avg rtt 289 µs, ttl = 64 9: rtt 259 µs, avg rtt 286 µs, ttl = 64 For the test, I simply hget'ed the kertex tarball. This is always 28kB/s... So even downloading 10MB takes more than 6 minutes. For the version, i don't know: I downloaded the iso distrib from the Bell Labs web site, some weeks ago, when the site was still online. The problem is that I tried 3 versions of the distrib: USB and iso from 9atom (but the kernels panic'ed with my hardware); and the Bell Labs iso (the kernel booted, but there were further problems with USB so I ended up making the install "by hand", but with the files from the Bell Labs iso). > > rtl8169: unknown mac 8168 4c00 > > my version of the driver handles this hardware Unfortunately see above: the 9atom kernels crashed for my hardware (bicore Intel Pentium G3220). > > > i8042: fe returned to the ea command > > you don't have a ps2 mouse, but the system is configured to expect one. > 0xea -> set streaming. Thanks for the explanation. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] rtl8169 gbe slow
I have compared downloading a file (via ftpfs) on the LAN, and downloading it from the WAN. On the LAN, I get the 10MB file in less than a 1s (this is normal since the node I download from has only a 100Mb ethernet). On the WAN, it takes 6 minutes (with hget). My conclusion is that the card device (driver) is not at fault but that something is wrong along the path when I get through the gateway. Has somebody an idea about what I may do wrong or what could cause such a cost on the gateway. I have set IPv6 on the gateway: no difference. I have tried to disable IPv6 on the ether: no difference. ip/traceroute to the outside server shows results that are on par with what I get from NetBSD on this very node where I run also plan9. "Something" is obviously wrong. But "what" is less obvious (at least to me). -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
