Yes. You can't have it both ways. If you don't want to use 'untested' or 'unstable' software, then you have to accept that a stable kernel series like 2.4 means not adding new features unless they are important bugfixes.
If this network is to stretch across the USA then no matter how fast it transfers data, there will still be a noticeable latency between one end and the other. The speed of light is not getting any faster. The limiting factor for serving files over NFS, for example, might end up being latency rater than bandwidth or server performance (if CPUs are also getting faster and RAM cheaper).
Perhaps in the future bandwidth will be an almost infinite resource and protocols will be designed around minimizing latency. For example for a remote filesystem you might design a server that spews out all changes to all files as they happen - to every other host that is looking at the filesystem. The bandwidth cost of sending unnecessary files is not significant, and it means a saving in latency because file data will be immediately available at the client end rather than requiring a round trip. (This assumes you don't care about locking and race conditions - but classical NFS doesn't anyway.)
Similarly, web servers might be designed to spew forth a whole bunch of pages you might possibly be interested in as soon as you connect to their site, and your browser's job is to cache them and then show the ones you want. If you want a page that isn't in the set the server sent you, you'll need to make another round trip, and that could be the slowest part. We will certainly need something like this for interplanetary web browsing at acceptable speeds.
I think a reasonable rule of thumb is that you make your app work on platform X if and when someone sends you patches to support it. Then you don't divert too much of your own effort towards platforms that nobody wants, but if someone was concerned enough to make patches for a platform then either (a) the patches must be trivial enough to be worth including or (b) the platform must be important enough to at least some people. Of course you can reject a patch that gunges up the whole source tree with '#ifdef AIX' and ask the contributor to do it more cleanly, with a port/aix.h file defining the missing functions or whatever. This is how Portable OpenSSH adds support for new platforms - try to keep the core code relatively untouched and encapsulate that platform's workarounds in one or two new source files.
For authentication you commonly encrypt some text (for example a checksum of the message) with your private key, and then anyone who has your public key can decrypt it and verify that you really did write that message (or at least whoever wrote it had your private key).
I don't think there is any such thing as a portable Makefile for large projects. There are just too many strange bugs or oddities in shells and make in different Unix variants. There is very little standardization in the more advanced compiler or linker flags, for example.
Similarly, portable application source code is rather difficult in many cases. You can write to a standard like ISO C or ISO C++, but then what do you do about the systems that don't quite conform to that standard? Being portable to many systems in practice may mean writing 'non-portable' code in some cases and using an autoconf/automake style mechanism to choose what to compile.
Maybe you're right - in this day and age when almost everybody uses GNU, BSD or other sane and non-crusty Unix variant, it's not worth trying to cope with all of them. In the earlier days it was necessary to have GNU packages build on all sorts of proprietary Unix variants, hence autoconf.
However, even if you do let other people provide the necessary patches for other platforms, there's something to be said for having a central repository of these patches. If I happen to use a weird system where the arguments to strcpy() are the wrong way round, I can write an autoconf test for this, it can be added to the standard set of autoconf macros, and then any project can make use of it to port to my platform. Also, if the changes to program source code are fairly small, it can make more sense to incorporate them in the main source tree so that they can more easily stay up to date - rather than having a dozen patch sets maintained by disparate people. Okay, Gentoo or other Linux distributions will do a good job of maintaining their own patches, but if you want your app to run on AIX 4.x do you really expect IBM to create and maintain the port?
Unlike many Slashdot posters you don't make the mistake of attacking autoconf or similar systems without considering the problem it needs to address. As you say, the choice is to support many platforms with some mechanism like autoconf, or to focus on just one platform and let others make ports. But not every project wants to focus on one platform. Would you suggest that KDE, for example, should drop Solaris and FreeBSD support and concern itself only with running on Linux? Wouldn't that cut out a chunk of the core developers?
Windows NT used to have native support for OS/2 HPFS; it was included in NT 3.51 as pinball.sys, it wasn't there with NT 4 but you could copy pinball.sys across and have it work. I don't know if this old driver still works with current Windows versions.
Icewm has a full screen mode with Alt-F11. I run a few windows (xterm, xemacs, xdvi, dillo) full screen and switch between them with Alt-Tab. But if you want to go back to a more conventional desktop just hit Alt-F11 again to restore the normal window size.
Checking that enough memory is definitely available for a fork() wouldn't make the speed drop significantly; all the kernel must do is make sure the memory is available and mark it as used, not actually allocate it and map it into the process's address space. You can still have copy-on-write as long as the space is there in case you need it later.
You would need more swap space, with most of it sitting unused most of the time 'just in case', but I don't think this is too bad: 60 gigs seems like a too-big estimate. Something like ten times physical RAM would be enough, surely, and that is easily affordable on modern hardware. Again, having extra swap space available doesn't mean more swapping will happen - only that if the memory is used later, the reserved swap space is there ready for use, rather than getting out of memory and killing processes.
OK - for desktop systems and most servers I think it's reasonable to have overallocation. Certainly for fork() and probably for malloc(), although I would like a malloc_yes_really() call for writing daemons which need to stay running no matter what and which do their own out-of-memory recovery.
But the article was talking about embedded systems. These often don't have swap space, but do have software which is aware of the memory limitations and tries to do the right thing. It can't do that if the kernel plays games with memory allocation and pretends to have space that isn't there. So guaranteed memory allocation needs to be available as an option, even if it's not the default.
Er - malloc()? In C++ you use 'new' for allocating memory on the heap. And yes, that should throw an exception unless you use new (nothrow) or the like.
But malloc() isn't the kernel interface I think - if malloc() misbehaves that's only a symptom of what the kernel is doing wrong. C++'s new would presumably suffer the same problem. Unless you wrote an allocator which tests the newly-allocated memory to make sure the kernel wasn't lying... ugh.
Well yes, and if an airline overbooks you can get kicked off a flight (in the worst case when there are no free seats to bump you to a higher class). Similarly if malloc() allocates some memory that isn't really there the process can get killed later. That doesn't seem like a good way to build reliable systems - wouldn't it make more sense to have malloc() honsestly return null if it can't guarantee the memory is available? At least processes can catch that and handle it gracefully (even if many don't in practice).
I just don't see the point of it - if people really do want 'malloc() with possible overallocation and random killing of processes later on' then there should be a separate function for that. But malloc() is malloc().
Suppose that open() didn't really open the file, but always returned true and hoped that the file would be there later when you tried to use it. It would become much more difficult to write programs which gracefully recover from file-not-found.
OK - your post was intended in jest - I had a temporary sense-of-humour failure and wrote the above rant. Eh, now I've written it I might as well post it.
# malloc doesn't return NULL.
Many embedded developers are used to writing code that relies on the fact that malloc will return NULL when physical memory is exhausted. The 'over-commit' strategy of the Linux allocator confuses the traditional embedded developer - particularly when there is no actual paging file in use.
I never understood that - if the machine doesn't have enough memory to guarantee that you can use the block returned from malloc(), why does it pretend to? Should there be two calls malloc_if_youre_lucky() and malloc_yes_i_mean_it(), with the latter returning a non-null pointer only if the memory really is available?
The article makes five points about 'the Linux community'. Points 1, and 3 - too many developers scratch the same itch or the wrong itch - apply to free software developers. The other supposed points: people 'spend as long taking potshots as developing', have a 'with or against' mentality, or are obsessed with Microsoft - do not apply to most free software developers but to hordes of hangers-on, cluebies and Slashdot weenies. Um, present company excepted, of course. Because the article hopelessly mixes these two things I don't think it makes much sense.
The trouble is that for every link you add to an index page you get one less allowed to point further down the tree, so getting even fewer than 343 leaf pages. Unless you make sure that all the links in index pages are ones you wanted to make anyway, and not duplicated anywhere else.
Yes I should have said 343 leaf pages. Presumably the index pages (which have seven links to more deeply-nested sections) could not contain content of their own, or at least, not content which has any links of its own (so ruling out most hypertext).
If you can have at most three clicks... and only seven choices at each point... then your site can hold only 7 ** 3 == 343 pages! So clearly at least one of the two rules is bogus.
100A x 12V is 1.2kW, that's a huge amount for a computer. Even today's overheated Pentium monsters use only about 400W (if the power supply ratings are to be believed - and I don't know whether that refers to the power drawn from the mains or supplied to the motherboard). My two-year-old LCD says on the back that it draws 3A at 12V DC.
More likely a PC would continue to be plugged in to the standard mains outlets, as at present. It's all the other electronic gizmos that have proliferated that cause the problem. So 10A per person should be plenty. It seems wasteful to install a full mains socket for each one of those when it draws only a fraction of what that socket is designed for. Still, I suppose students can easily get one of those multi-socket adaptor thingies if they know that each device draws only a little current.
Still, you're right about the wiring - I hadn't really considered just how long it would need to be.
I doubt there's been a sudden surge in student usage of toasters, kettles, electric heaters or other appliances drawing a large amount of power. All the electonic devices that have recently become popular are low-voltage - 12V or less. So why is the answer to put in more high-voltage AC outlets, requiring a trained electrician? It would make more sense to run a 12V or 5V power supply within the building, if there were some way to connect devices to it.
Why not some kind of wiki? You type into a text box, press OK and it appears on the page. But not every wiki has good support for pictures.
Re:The main issue with XML is performance
on
Effective XML
·
· Score: 3, Informative
If you know your XML will conform to a particular DTD, FleXML can be used to generate a very fast parser for it in the style of lex/yacc. You don't have to mess with all that slow DOM or SAX stuff if you're concerned about speed. It may still be a resource hog compared with binary file formats and protocols but not nearly as sucky as often seen (my own code included).
Heh, shows how long it has been since I last visited their site and logged in... nowadays I don't bother unless someone finds the publicly-accessible link.
Slashdot Mirror
Yes. You can't have it both ways. If you don't want to use 'untested' or 'unstable' software, then you have to accept that a stable kernel series like 2.4 means not adding new features unless they are important bugfixes.
If this network is to stretch across the USA then no matter how fast it transfers data, there will still be a noticeable latency between one end and the other. The speed of light is not getting any faster. The limiting factor for serving files over NFS, for example, might end up being latency rater than bandwidth or server performance (if CPUs are also getting faster and RAM cheaper).
Perhaps in the future bandwidth will be an almost infinite resource and protocols will be designed around minimizing latency. For example for a remote filesystem you might design a server that spews out all changes to all files as they happen - to every other host that is looking at the filesystem. The bandwidth cost of sending unnecessary files is not significant, and it means a saving in latency because file data will be immediately available at the client end rather than requiring a round trip. (This assumes you don't care about locking and race conditions - but classical NFS doesn't anyway.)
Similarly, web servers might be designed to spew forth a whole bunch of pages you might possibly be interested in as soon as you connect to their site, and your browser's job is to cache them and then show the ones you want. If you want a page that isn't in the set the server sent you, you'll need to make another round trip, and that could be the slowest part. We will certainly need something like this for interplanetary web browsing at acceptable speeds.
I think a reasonable rule of thumb is that you make your app work on platform X if and when someone sends you patches to support it. Then you don't divert too much of your own effort towards platforms that nobody wants, but if someone was concerned enough to make patches for a platform then either (a) the patches must be trivial enough to be worth including or (b) the platform must be important enough to at least some people. Of course you can reject a patch that gunges up the whole source tree with '#ifdef AIX' and ask the contributor to do it more cleanly, with a port/aix.h file defining the missing functions or whatever. This is how Portable OpenSSH adds support for new platforms - try to keep the core code relatively untouched and encapsulate that platform's workarounds in one or two new source files.
For authentication you commonly encrypt some text (for example a checksum of the message) with your private key, and then anyone who has your public key can decrypt it and verify that you really did write that message (or at least whoever wrote it had your private key).
I don't think there is any such thing as a portable Makefile for large projects. There are just too many strange bugs or oddities in shells and make in different Unix variants. There is very little standardization in the more advanced compiler or linker flags, for example.
Similarly, portable application source code is rather difficult in many cases. You can write to a standard like ISO C or ISO C++, but then what do you do about the systems that don't quite conform to that standard? Being portable to many systems in practice may mean writing 'non-portable' code in some cases and using an autoconf/automake style mechanism to choose what to compile.
Maybe you're right - in this day and age when almost everybody uses GNU, BSD or other sane and non-crusty Unix variant, it's not worth trying to cope with all of them. In the earlier days it was necessary to have GNU packages build on all sorts of proprietary Unix variants, hence autoconf.
However, even if you do let other people provide the necessary patches for other platforms, there's something to be said for having a central repository of these patches. If I happen to use a weird system where the arguments to strcpy() are the wrong way round, I can write an autoconf test for this, it can be added to the standard set of autoconf macros, and then any project can make use of it to port to my platform. Also, if the changes to program source code are fairly small, it can make more sense to incorporate them in the main source tree so that they can more easily stay up to date - rather than having a dozen patch sets maintained by disparate people. Okay, Gentoo or other Linux distributions will do a good job of maintaining their own patches, but if you want your app to run on AIX 4.x do you really expect IBM to create and maintain the port?
Unlike many Slashdot posters you don't make the mistake of attacking autoconf or similar systems without considering the problem it needs to address. As you say, the choice is to support many platforms with some mechanism like autoconf, or to focus on just one platform and let others make ports. But not every project wants to focus on one platform. Would you suggest that KDE, for example, should drop Solaris and FreeBSD support and concern itself only with running on Linux? Wouldn't that cut out a chunk of the core developers?
Windows NT used to have native support for OS/2 HPFS; it was included in NT 3.51 as pinball.sys, it wasn't there with NT 4 but you could copy pinball.sys across and have it work. I don't know if this old driver still works with current Windows versions.
Icewm has a full screen mode with Alt-F11. I run a few windows (xterm, xemacs, xdvi, dillo) full screen and switch between them with Alt-Tab. But if you want to go back to a more conventional desktop just hit Alt-F11 again to restore the normal window size.
Why shouldn't the same company produce exploit code and the tools to combat it? It's common for security groups to do that.
Checking that enough memory is definitely available for a fork() wouldn't make the speed drop significantly; all the kernel must do is make sure the memory is available and mark it as used, not actually allocate it and map it into the process's address space. You can still have copy-on-write as long as the space is there in case you need it later.
You would need more swap space, with most of it sitting unused most of the time 'just in case', but I don't think this is too bad: 60 gigs seems like a too-big estimate. Something like ten times physical RAM would be enough, surely, and that is easily affordable on modern hardware. Again, having extra swap space available doesn't mean more swapping will happen - only that if the memory is used later, the reserved swap space is there ready for use, rather than getting out of memory and killing processes.
OK - for desktop systems and most servers I think it's reasonable to have overallocation. Certainly for fork() and probably for malloc(), although I would like a malloc_yes_really() call for writing daemons which need to stay running no matter what and which do their own out-of-memory recovery.
But the article was talking about embedded systems. These often don't have swap space, but do have software which is aware of the memory limitations and tries to do the right thing. It can't do that if the kernel plays games with memory allocation and pretends to have space that isn't there. So guaranteed memory allocation needs to be available as an option, even if it's not the default.
Er - malloc()? In C++ you use 'new' for allocating memory on the heap. And yes, that should throw an exception unless you use new (nothrow) or the like.
But malloc() isn't the kernel interface I think - if malloc() misbehaves that's only a symptom of what the kernel is doing wrong. C++'s new would presumably suffer the same problem. Unless you wrote an allocator which tests the newly-allocated memory to make sure the kernel wasn't lying... ugh.
Well yes, and if an airline overbooks you can get kicked off a flight (in the worst case when there are no free seats to bump you to a higher class). Similarly if malloc() allocates some memory that isn't really there the process can get killed later. That doesn't seem like a good way to build reliable systems - wouldn't it make more sense to have malloc() honsestly return null if it can't guarantee the memory is available? At least processes can catch that and handle it gracefully (even if many don't in practice).
I just don't see the point of it - if people really do want 'malloc() with possible overallocation and random killing of processes later on' then there should be a separate function for that. But malloc() is malloc().
Suppose that open() didn't really open the file, but always returned true and hoped that the file would be there later when you tried to use it. It would become much more difficult to write programs which gracefully recover from file-not-found.
OK - your post was intended in jest - I had a temporary sense-of-humour failure and wrote the above rant. Eh, now I've written it I might as well post it.
If this thing lets you load your own software, you could presumably use it as your main PC, at least for non-computron-intensive applications.
The article makes five points about 'the Linux community'. Points 1, and 3 - too many developers scratch the same itch or the wrong itch - apply to free software developers. The other supposed points: people 'spend as long taking potshots as developing', have a 'with or against' mentality, or are obsessed with Microsoft - do not apply to most free software developers but to hordes of hangers-on, cluebies and Slashdot weenies. Um, present company excepted, of course. Because the article hopelessly mixes these two things I don't think it makes much sense.
The trouble is that for every link you add to an index page you get one less allowed to point further down the tree, so getting even fewer than 343 leaf pages. Unless you make sure that all the links in index pages are ones you wanted to make anyway, and not duplicated anywhere else.
Yes I should have said 343 leaf pages. Presumably the index pages (which have seven links to more deeply-nested sections) could not contain content of their own, or at least, not content which has any links of its own (so ruling out most hypertext).
If you can have at most three clicks... and only seven choices at each point... then your site can hold only 7 ** 3 == 343 pages! So clearly at least one of the two rules is bogus.
I meant to say - 1.2kW is a huge amount for consumer electronics, even including a PC (which is surely the most power-hungry item).
100A x 12V is 1.2kW, that's a huge amount for a computer. Even today's overheated Pentium monsters use only about 400W (if the power supply ratings are to be believed - and I don't know whether that refers to the power drawn from the mains or supplied to the motherboard). My two-year-old LCD says on the back that it draws 3A at 12V DC.
More likely a PC would continue to be plugged in to the standard mains outlets, as at present. It's all the other electronic gizmos that have proliferated that cause the problem. So 10A per person should be plenty. It seems wasteful to install a full mains socket for each one of those when it draws only a fraction of what that socket is designed for. Still, I suppose students can easily get one of those multi-socket adaptor thingies if they know that each device draws only a little current.
Still, you're right about the wiring - I hadn't really considered just how long it would need to be.
I doubt there's been a sudden surge in student usage of toasters, kettles, electric heaters or other appliances drawing a large amount of power. All the electonic devices that have recently become popular are low-voltage - 12V or less. So why is the answer to put in more high-voltage AC outlets, requiring a trained electrician? It would make more sense to run a 12V or 5V power supply within the building, if there were some way to connect devices to it.
Why not some kind of wiki? You type into a text box, press OK and it appears on the page. But not every wiki has good support for pictures.
If you know your XML will conform to a particular DTD, FleXML can be used to generate a very fast parser for it in the style of lex/yacc. You don't have to mess with all that slow DOM or SAX stuff if you're concerned about speed. It may still be a resource hog compared with binary file formats and protocols but not nearly as sucky as often seen (my own code included).
Heh, shows how long it has been since I last visited their site and logged in... nowadays I don't bother unless someone finds the publicly-accessible link.