Feh. The original Elite fitted on a 100 kilobyte floppy. Apart from the cassette version (with fewer ships) which ran in 32 kilobytes, including 10K or so for video memory.
Why does an interactive process want to use all the CPU? I'd guess a user could only load a decent app up to 15% of modern CPUs.
In reply I said that 15% could be the _average_ CPU usage but 100% CPU is needed occasionally when the user has just performed an action.
I agree with you: it is possible to give the interactive process 100% CPU when it wants it, in short bursts, and go back to server scheduling for the other processes. That is exactly the point I was making.
Yes they can get the key out of you ('rubber hose cryptanalysis') but there are some systems where you can have several keys and each key reveals different data - so you could disclose a key which gives a dummy, fairly uninformative address book. Then there is no way to show that extra data is hidden unless you have the extra keys. This means that when you say 'I have told you everything I know' there is no way to verify that claim. This has both good and bad points.
Disguising the data in something else like a minidisk recorder is a good idea but obviously not everyone can do that - each person must choose a different kind of disguise, so it gets tricky.
The encryption system has two parts: an algorithm, which is publicly known, and a key, which is private. You need both to decrypt some data. The system is designed so that the key is required for decryption, it is not enough just to know the algorithm.
OK - it might be a little bit harder if you didn't know the algorithm either, but would you trust an encryption system where the author said 'we can't disclose how it works, we're worried that if people knew that they might be able to break it'?
open(FH, 'file') or die;
print FH "test\n" or die;
close FH or die;
This code is much simpler in a language (like Python) that throws an exception when something goes wrong rather expecting you to remember to check the return value every single time.
(Yeah yeah I know the quotation: 'failing to open a file is hardly exceptional'. I submit that what's truly exceptional is the time when you don't want to throw an error on opening a file but instead handle the problem at the same level. It's that less common case that should require extra code, not the more common case of 'if the file couldn't be opened, throw an exception and let the caller handle it if he wants'.)
An interactive program might use only 15% of the CPU *on average*, because most of the time it is waiting for user input, but it does need to use 100% CPU in short bursts to respond quickly to the user.
Not at all. Indeed the lkml thread referenced was about getting good performance when there are some non-interactive processes such as gcc and some interactive ones such as MP3 players or the X server.
Suppose there are two CPU-bound processes marked as 'batch' and one process marked as 'interactive' which spends most of its time waiting for user input, but needs to respond quickly in short bursts when that input happens. The interactive process will get high priority and preempt the two batch processes when it needs to run; but when it goes back to sleep the two batch processes are scheduled with long timeslices.
There's no reason not to implement both high-throughput scheduling for big servers and low-latency scheduling for desktops in the same kernel... just mark each process table entry with a bit saying whether this process is 'interactive' (favour fairness and low response times) or 'batch' (favour total throughput and bigger timeslices at the expense of fairness).
I agree, static linking sucks. And putting each app's DLLs into its own directory sucks for the same reasons. If you ran five different image editors at once and each had its own copy of foo.dll in its own directory then five copies of the DLL would also be loaded. The real advantage of dynamic linking is only realized when shared libraries are actually *shared*.
The amount of times I've hit my binding for "close window" and had a mozilla session with 30 or so tabs open close on me....
Many people have filed feature requests against Mozilla or Phoenix for some warning before this happens, but the UI designers reject these requests. In some way it is more consistent for the window's 'close' button to just close everything without warning, although I agree it is a damn stupid behaviour in practice and I wish it were fixed.
If tabs were implemented by the window manager, instead of on an ad-hoc basis for each application, then questions like 'should closing the main window make all tabs instantly vanish' would be part of the wm preferences.
Yes konsole has tabs, yes they are useful, but why does the tabbing have to be different for every app? Why can't _every_ application have tabs that act the same way? If tabs are useful with konqueror, wouldn't it also be good to have them in your editor, or spreadsheet, maybe even in graphics programs like the GIMP?
'Close' and 'minimize' are useful features too. But we don't require each program to implement them indepedently and with slightly different conventions. They're provided by the window manager so they work the same way for all apps. (Of course, an app can hint to the window manager that certain dialogue boxes might not need a title bar or minimize button.) It would be cool if tabs worked the same way.
Quoting, with the ">" symbol, is a disease that makes it impossible to read any single thread without boring yourself to death by re-reading the whole history of a chain of argument which you just read in the original, seconds ago, again and again and again.
Quite the opposite - quoting is the convention that makes it possible to read a message and get an immediate idea of what is discussed, _without_ having to go back and wade through old history. It just relies on people to have the discipline to quote what is relevant and not just paste in the whole previous message. Of course if you summarize the 'story so far' in your own words, you don't need to quote anything at all.
The feature I would remove from a forum system is subject lines. And that because of the incredibly annoying style (to me) of using the subject line as a first line of the post. So then if you just read the body it doesn't make any sense. Most other forms of writing (newspapers, well-written mail messages and Usenet articles) are designed so you can read the message body independently of the subject.
The fact that so many posters don't give a proper subject but instead put the first line of the message in there suggests that the subject line isn't really needed anyway. Better to just have a message body. (And it would be really trivial to let users browse through just the first line of a long list of posts and choose the one they want.)
When starting a new thread I can often not think of a decent subject myself. It's different on Usenet where a single group covers a fairly wide range of topics. On a Slashdot discussion page the article title is usually the 'subject' and posts on that page are all related to the article. So an extra subject line on each post feels artificial.
Tabbed browsing is useful. But it shouldn't be necessary; tabs should be implemented by the *window manager*, then they would be available with the same interface for all applications.
Imagine how crazy it would be if each app implemented its own title bar and close button on every window. Now think about the current situation with tabs in Mozilla, tabs in terminal emulators, tabs in XEmacs...
It doesn't really matter whether it is fair use or not: what matters is that it be so obviously, unequivocally fair use that even the most sleazy lawyer would never try sending out a cease-and-desist letter.
Unless you have the money to hire lawyers of your own, you have to tread very carefully around the edges of the law and avoid things that 'might be illegal' as well as those that really are.
It's okay for the app to install its own DLLs - if the developer of Fred Enterprise Edition decides that it simplifies development to move a lot of the code into libfred.dll, fair enough. As you say, the difficulty is when apps depend on _outside_ DLLs but decide to come with their own (possibly outdated) versions of those libraries.
That's what I object to - if an app depends on MFC it should require the administrator install the MFC package from Microsoft first. It makes no sense to have ten app installers each with their own copy of mfc42.dll.
If the app puts its own library in its own directory then it might as well just be statically linked. In both cases you lose all the advantages of dynamic linking: lower disk and memory footprint, faster app startup, and crucially the ability to upgrade a library (to a compatible, newer version) and get its new features or bug fixes in all apps using that library.
I think a system you propose could catch on, for the simple reason that it makes hard disks cheaper to manufacture. Look at the replacement of modems by Winmodems for example.
All that needs to happen is for the hard disk to come with a CD containing drivers for $POPULAR_OS. If you don't use such an OS you can still address the disk as a flat list of sectors, and get slightly worse performance.
Yes, maybe it is a bit 'ick' but nobody nowadays blinks an eyelid at needing special drivers for each different network card or graphics card. I'd be willing to accept such a setup if it made hard disks 10% cheaper and hopefully a bit faster. Provided, of course, that free drivers are available for free OSes (and this may be the problem).
A cleaner solution would be to do things right and make sure that applications don't install random DLLs to start with. If an app needs foo.dll then it should be up to the administrator to install the package providing that library beforehand - or an automated dependency analysis in Windows's package manager could do this. This would also have the happy side effect of making app downloads less bloated.
Why is the drive firmware doing this stuff at all - why can't the OS do the job of deciding where to move the disk head and reordering request queues? I thought that was what all the elevator disk scheduling code in OSes was for.
Something that interests me is the trend for code quality analysis tools to pick the Linux kernel or other well-known free program as an example. So researchers developing the tool get to boast 'we found 47 bugs in Linux', which is a statistic people can understand (even if it may not always be strictly true), while Linux benefits from some extra bug reports.
Strictly speaking, static analysis tools measure what is called kwalitee, a property which isn't the same as code quality but is usually closely correlated with it. In other words the tools do make mistakes, but most of the time they are on the right track.
It would also be possible to have a big online 'databank' of C source from many projects - the top thousand on Sourceforge plus the GNU programs, or something like that - and make this a standard 'corpus' for code analysis tools.
Hmm, I have to get a question out of this. Do you think that code analysis tools like Splint could improve free software quality further? What sort of infrastructure could be created for doing code kwalitee checks across a whole Linux or BSD distribution?
So while subscribers won't see news posted at the last minute before everyone else, most of our stories will be available to them 10-20 minutes before everyone else. This means they can click through and beat the Slashdot Effect.
...if they reload Slashdot every quarter of an hour or so. Who does that all day long?
Depends what you want to run: 16 megs is more than enough for Linux + X + Icewm + some editor (vi, joe, nano, heck even GNU Emacs) + LaTeX. Although I admit that most non-techie users will not be running LaTeX.
I'd be surprised if the GTK version of Abiword didn't run acceptably well in 16 megs. Combine that with the Dillo web browser and a mail program such as Sylpheed, and you have a decent system.
Come _on_ people, it was only a few years ago that 64 megs of memory was ridiculously expensive. Do you really believe that nobody ran Linux, or X, or any applications back then?
Slashdot Mirror
Feh. The original Elite fitted on a 100 kilobyte floppy. Apart from the cassette version (with fewer ships) which ran in 32 kilobytes, including 10K or so for video memory.
In reply I said that 15% could be the _average_ CPU usage but 100% CPU is needed occasionally when the user has just performed an action.
I agree with you: it is possible to give the interactive process 100% CPU when it wants it, in short bursts, and go back to server scheduling for the other processes. That is exactly the point I was making.
Yes they can get the key out of you ('rubber hose cryptanalysis') but there are some systems where you can have several keys and each key reveals different data - so you could disclose a key which gives a dummy, fairly uninformative address book. Then there is no way to show that extra data is hidden unless you have the extra keys. This means that when you say 'I have told you everything I know' there is no way to verify that claim. This has both good and bad points.
Disguising the data in something else like a minidisk recorder is a good idea but obviously not everyone can do that - each person must choose a different kind of disguise, so it gets tricky.
The encryption system has two parts: an algorithm, which is publicly known, and a key, which is private. You need both to decrypt some data. The system is designed so that the key is required for decryption, it is not enough just to know the algorithm.
OK - it might be a little bit harder if you didn't know the algorithm either, but would you trust an encryption system where the author said 'we can't disclose how it works, we're worried that if people knew that they might be able to break it'?
I nominate '... or die;'.
open(FH, 'file') or die;
print FH "test\n" or die;
close FH or die;
This code is much simpler in a language (like Python) that throws an exception when something goes wrong rather expecting you to remember to check the return value every single time.
(Yeah yeah I know the quotation: 'failing to open a file is hardly exceptional'. I submit that what's truly exceptional is the time when you don't want to throw an error on opening a file but instead handle the problem at the same level. It's that less common case that should require extra code, not the more common case of 'if the file couldn't be opened, throw an exception and let the caller handle it if he wants'.)
Huh? There is no such thing as 'a dual processor'. A dual-processor board means a motherboard with two CPUs on it. That is all.
An interactive program might use only 15% of the CPU *on average*, because most of the time it is waiting for user input, but it does need to use 100% CPU in short bursts to respond quickly to the user.
Not at all. Indeed the lkml thread referenced was about getting good performance when there are some non-interactive processes such as gcc and some interactive ones such as MP3 players or the X server.
Suppose there are two CPU-bound processes marked as 'batch' and one process marked as 'interactive' which spends most of its time waiting for user input, but needs to respond quickly in short bursts when that input happens. The interactive process will get high priority and preempt the two batch processes when it needs to run; but when it goes back to sleep the two batch processes are scheduled with long timeslices.
There's no reason not to implement both high-throughput scheduling for big servers and low-latency scheduling for desktops in the same kernel... just mark each process table entry with a bit saying whether this process is 'interactive' (favour fairness and low response times) or 'batch' (favour total throughput and bigger timeslices at the expense of fairness).
We all secretly envy Joel Spolsky because he gets to develop in Visual Basic.
I agree, static linking sucks. And putting each app's DLLs into its own directory sucks for the same reasons. If you ran five different image editors at once and each had its own copy of foo.dll in its own directory then five copies of the DLL would also be loaded. The real advantage of dynamic linking is only realized when shared libraries are actually *shared*.
Many people have filed feature requests against Mozilla or Phoenix for some warning before this happens, but the UI designers reject these requests. In some way it is more consistent for the window's 'close' button to just close everything without warning, although I agree it is a damn stupid behaviour in practice and I wish it were fixed.
If tabs were implemented by the window manager, instead of on an ad-hoc basis for each application, then questions like 'should closing the main window make all tabs instantly vanish' would be part of the wm preferences.
Yes konsole has tabs, yes they are useful, but why does the tabbing have to be different for every app? Why can't _every_ application have tabs that act the same way? If tabs are useful with konqueror, wouldn't it also be good to have them in your editor, or spreadsheet, maybe even in graphics programs like the GIMP?
'Close' and 'minimize' are useful features too. But we don't require each program to implement them indepedently and with slightly different conventions. They're provided by the window manager so they work the same way for all apps. (Of course, an app can hint to the window manager that certain dialogue boxes might not need a title bar or minimize button.) It would be cool if tabs worked the same way.
The feature I would remove from a forum system is subject lines. And that because of the incredibly annoying style (to me) of using the subject line as a first line of the post. So then if you just read the body it doesn't make any sense. Most other forms of writing (newspapers, well-written mail messages and Usenet articles) are designed so you can read the message body independently of the subject.
The fact that so many posters don't give a proper subject but instead put the first line of the message in there suggests that the subject line isn't really needed anyway. Better to just have a message body. (And it would be really trivial to let users browse through just the first line of a long list of posts and choose the one they want.)
When starting a new thread I can often not think of a decent subject myself. It's different on Usenet where a single group covers a fairly wide range of topics. On a Slashdot discussion page the article title is usually the 'subject' and posts on that page are all related to the article. So an extra subject line on each post feels artificial.
Tabbed browsing is useful. But it shouldn't be necessary; tabs should be implemented by the *window manager*, then they would be available with the same interface for all applications.
Imagine how crazy it would be if each app implemented its own title bar and close button on every window. Now think about the current situation with tabs in Mozilla, tabs in terminal emulators, tabs in XEmacs...
It doesn't really matter whether it is fair use or not: what matters is that it be so obviously, unequivocally fair use that even the most sleazy lawyer would never try sending out a cease-and-desist letter.
Unless you have the money to hire lawyers of your own, you have to tread very carefully around the edges of the law and avoid things that 'might be illegal' as well as those that really are.
It's okay for the app to install its own DLLs - if the developer of Fred Enterprise Edition decides that it simplifies development to move a lot of the code into libfred.dll, fair enough. As you say, the difficulty is when apps depend on _outside_ DLLs but decide to come with their own (possibly outdated) versions of those libraries.
That's what I object to - if an app depends on MFC it should require the administrator install the MFC package from Microsoft first. It makes no sense to have ten app installers each with their own copy of mfc42.dll.
If the app puts its own library in its own directory then it might as well just be statically linked. In both cases you lose all the advantages of dynamic linking: lower disk and memory footprint, faster app startup, and crucially the ability to upgrade a library (to a compatible, newer version) and get its new features or bug fixes in all apps using that library.
I think a system you propose could catch on, for the simple reason that it makes hard disks cheaper to manufacture. Look at the replacement of modems by Winmodems for example.
All that needs to happen is for the hard disk to come with a CD containing drivers for $POPULAR_OS. If you don't use such an OS you can still address the disk as a flat list of sectors, and get slightly worse performance.
Yes, maybe it is a bit 'ick' but nobody nowadays blinks an eyelid at needing special drivers for each different network card or graphics card. I'd be willing to accept such a setup if it made hard disks 10% cheaper and hopefully a bit faster. Provided, of course, that free drivers are available for free OSes (and this may be the problem).
A cleaner solution would be to do things right and make sure that applications don't install random DLLs to start with. If an app needs foo.dll then it should be up to the administrator to install the package providing that library beforehand - or an automated dependency analysis in Windows's package manager could do this. This would also have the happy side effect of making app downloads less bloated.
Why is the drive firmware doing this stuff at all - why can't the OS do the job of deciding where to move the disk head and reordering request queues? I thought that was what all the elevator disk scheduling code in OSes was for.
Something that interests me is the trend for code quality analysis tools to pick the Linux kernel or other well-known free program as an example. So researchers developing the tool get to boast 'we found 47 bugs in Linux', which is a statistic people can understand (even if it may not always be strictly true), while Linux benefits from some extra bug reports.
Strictly speaking, static analysis tools measure what is called kwalitee, a property which isn't the same as code quality but is usually closely correlated with it. In other words the tools do make mistakes, but most of the time they are on the right track.
It would also be possible to have a big online 'databank' of C source from many projects - the top thousand on Sourceforge plus the GNU programs, or something like that - and make this a standard 'corpus' for code analysis tools.
Hmm, I have to get a question out of this. Do you think that code analysis tools like Splint could improve free software quality further? What sort of infrastructure could be created for doing code kwalitee checks across a whole Linux or BSD distribution?
Depends what you want to run: 16 megs is more than enough for Linux + X + Icewm + some editor (vi, joe, nano, heck even GNU Emacs) + LaTeX. Although I admit that most non-techie users will not be running LaTeX.
I'd be surprised if the GTK version of Abiword didn't run acceptably well in 16 megs. Combine that with the Dillo web browser and a mail program such as Sylpheed, and you have a decent system.
Come _on_ people, it was only a few years ago that 64 megs of memory was ridiculously expensive. Do you really believe that nobody ran Linux, or X, or any applications back then?