In other words: stick to what you know. Let Winzip do the compression and archiving, and let someone else do the encryption. WTF is wrong with making a zipfile and then encrypting it with PGP? The only reasons to put encryption in Winzip itself are fairly bogus arguments about convenience, and the chance to charge more money for a product that does more (even if it does it badly).
I expected that Google would do something more like Gmane and start indexing existing mailing lists. The web search looks at existing pages, it doesn't let you make your own (unless that is coming?). But it looks like they want to make something better than Yahoo Groups, which should not be difficult.
I wonder if they will feed out the groups as NNTP, or as mailing lists which can be fed into Gmane. Then one will be able to read them with a convenient newsreader interface along with everything else.
It's 2004. Is there no way to run a program in a sandbox and give it limited privileges by default?
For example, you could run the app with read-only access to the filesystem, and no network access. To prevent noddy DoS attacks the process and its children could be limited to 100 megabytes of memory and ten fork() calls.
Better still, the app could have no access to any file apart from its own program code (ie, the files inside the application directory). If you want to view a file in the application, the file manager program passes it an open file descriptor to read from but only after you have explicitly selected the file in the file manager and asked to view it in the untrustworthy application.
This could also be done for IRC clients, web browsers and other programs where a serious enough bug could open up nasty ways for others to hijack your computer. There's no real reason to run these will full user privelege. They don't need the ability to delete arbitrary files from your home directory, so why do we grant it to them?
I know what bogomips are for, my point is that on a two-CPU system printing the 'total' number of bogomips by adding the two CPUs together is even more bogus;-P.
The only people using the bonded sender headers will be direct marketers. So surely you want to give the rule a positive score? I'd say +5 or so since such a header is an almost certain indication of spam. (Or if not strictly speaking spam, at least crud.)
The new chip opens up advanced applications to notebook computer users like full-screen high-definition video playing and mobile videoconferencing, while keeping the PC relatively light, Intel said.
Isn't that just what they said for the previous line of processors? If this new chip is needed for videoconferencing, are we to conclude that the previous chip couldn't do it, contrary to what Intel said at the time?
(My point is, reprinting inane press releases does nobody any good.)
I'm surprised that the marketing department missed the upcoming opportunity to label dual-core CPUs with 'twice' the clock speed, as is done for bogomips.
Are high-end servers still sold that won't take more than 16Gbyte (I assume you meant 16Gbyte not 16Gb) of RAM?
You have to compare these expensive RAM disks against two alternatives. Firstly, getting a server with a reasonable number of memory slots and loading it up with X gigabytes of memory; secondly, buying a dozen PCs, sticking four gigs of memory in each and having some wacky Gigabit Ethernet, SCSI, or Fibre Channel attachment to turn each one into a RAM disk. Although I expect that the power consumption for a PC would be higher, and it might take more space.
Reviews often mention the distribution's configuration tools. This makes sense, since they're one of relatively few features that really distinguish one distribution from another. But reviews don't normally go into enough depth or try hard enough to see how the distro copes with unusual breakage.
My pet hate is the PPP dialup in Red Hat - it's much too easy to get it into a wedged state by plugging and unplugging the phone line, and the diagnostics printed are very poor if you have something like the wrong PPP password. You can crash the wizard (spewing out Python diagnostics) if you press the Close button on the window at the wrong moment. When things work, it's fine, but when things break it is difficult to recover. These are faults common to many Linux setup wizardy things.
So I think reviewers should really try to mess things up a bit - yank out the Ethernet cable, power-cycle the machine without shutting down, change from one plug-and-play monitor to another and see if the distro correctly reconfigures. Maybe even edit some config files by hand and see if the config wizards can cope - and if they cannot cope, at least give a clean error message.
Reviews tend to give marks for having a long list of features but really it is more important to have a small set of features that are foolproof and rock-solid.
To hype anything as 'new' and 'revolutionary' is silly, since as we all know, nothing new has been invented since 1970. But there are certainly techniques which aren't as popular as they deserve to be. One is Delta Debugging as implemented by delta (a tool to automatically produce minimal test cases) and Ask Igor.
A Slashdot editor writes: "I am wondering the best way to write a headline for a reader's submission. I'm new to this and I always thought that a question has to have a verb and usually some kind of word like 'what' or 'how', but a lot of stories seem to manage by just sticking a question mark onto the end of some random words. What should I do?"
Nine out of ten businesses using free software isn't a big deal. A better milestone would be when only nine out of ten, or fewer, are using proprietary software.
When a customer needs something, it's added to or moved up the list. When a customer says "eh, I guess we can live without", something else ends up getting done first.
The fact that MySQL customers have not felt the need for stored procedures does not imply that they are 'just bloat' which is what you said. Note that MySQL customers are a self-selecting set of people who don't consider stored procedures (and to some extent, other RDBMS features like views, subqueries and high-concurrency ACID) to be that important. On the other hand, Oracle customers are self-selecting as people who do want that kind of thing and are willing to pay for it, so it might not be fair to judge MySQL on the basis of what Oracle customers want either. But when almost every other RDBMS supports these things, you see that MySQL is the odd one out, not Oracle.
DOS (specifically DR-DOS) still sells in some numbers, and DOS customers are not (on the whole) clamouring for lightweight threads or a journalling filesystem or multiuser security. This does not mean that these are not important features for most other operating systems. To say that DOS customers haven't been asking for them does not change the fact that they are highly valued for most of the rest of the world.
About the 'gotchas' - extensions to ANSI SQL is fine, but my feeling is that if I declare a column as 'int not null', I expect the value to be not null. No ifs, no buts. An 'extension' to the SQL semantics where the column can get populated with null values in certain odd cases and with no warning is very surprising and even dangerous. Almost any deviation from standards (indeed, any bug) can be counted as an 'extension' if you look at it the right way. The best thing would be for MySQL to have a standard mode and an extended mode; then these extra 'features' could be turned on or off depending on their merits.
You may be right that the people who want features like subqueries, views or stored procedures are not providing reasons but only whining. On the other hand, you are guilty of the same thing with blanket statements like 'Stored procedures and similar features are just bloat, and gain you no real advantage' - many programmers working with more advanced RDBMSes know otherwise. BTW, I also disagree with your assertion about subqueries being slow: you have to take care, yes, but like most things they are a very useful tool in the right hands and most simple uses of subqueries are not slow (at least on the databases I have most used, Oracle and Sybase).
I'm interested to know: have you ever run into the problems mentioned in MySQL Gotchas? Or are these deviations from the ANSI standards something that doesn't matter in practice.
You're right; I was thinking only of serializability (isolation of transactions) and not about durability or atomicity. Okay then: you could easily keep two copies of the database, perform the transaction on one, and if it succeeds copy all the data over to the other copy. If the transaction fails part way through you roll back from the other copy. You make sure disk buffers are flushed before performing the copy over. This takes care of both atomicity and durability. Again, it's not difficult to do: the challenge is in doing it and keeping performance.
A database benchmark of how fast you can perform a million insert statements is pretty meaningless: what matters (for large applications, anyway) is how fast you can serve a large number of clients in parallel, all performing updates, while preserving transactional integrity and never losing any data if the power cord is yanked. Any claim that database A is faster than database B should be taken with a pinch of salt unless you can be sure they are providing the same level of ACID guarantees.
...you have to say that a body of work worth billions of dollars has been created and placed in the public trust.
The LUGs can and should be the trustees or guardians that trust. Who else is going to do it? IBM? Novell?
That's why I think the LUGs have to expand their outlook to take in questions of the war and the military use of Linux.
Uh, yeah. That makes perfect sense.
It might have helped if he gave some suggestion of what the LUGs might _do_ about these questions, after all Linux (and even the GNU project) has always been about doing rather than posturing.
What you say about disregard for SQL standards is true, see MySQL Gotchas. Doing the wrong thing is not so bad, it's *silently* doing the wrong thing that you absoultely do not want in a database system. See also Why not MySQL, which is now rather dated (MySQL has grown some features since), but is a good introduction to what a database should do.
Note also that anyone can write a database system with complete transactional integrity: you simply lock the whole database for every single operation and run only one query or update at a time, one after the other. The challenge is in getting the semantics of serialized database access but with good performance. This is what schemes like row-level locking and multi-version concurrency are for.
I could write a simple application/shell script that, when run under the root account, could totally trash a Linux OS. Doesn't mean there's a bug with Linux.
True, but if you can write one as non-root that causes a _physical_ crash (as in locks up the machine so that the reset button doesn't work, or Alt-F2 doesn't switch virtual consoles, etc) then there certainly is a bug in Linux.
I thought that the crash being referred to earlier in this discussion was a hard failure of the OS. Also I didn't take into account that on WinDOS everything runs with full user privs. I was assuming Windows 2000 or some other NT-based system. I certainly would consider it a bug if any non-privileged executable could hard lock up an NT system for any reason (though it has been known, of course).
Likewise if you can bring down the X server by sending it bad requests (this is perhaps a closer analogy). But I'll admit that for code running in a privileged enough user account (eg local administrator rights on a Windows box) it is possible to do bad things without exploiting an OS bug.
Well - why didn't you say so? From everything you said so far I assumed you had some bug that only crashed your machine and nobody else's. However, there is still a bug in the OS and in an ideal world that would be fixed _first_. The Moz developers may be acting too idealistic in this respect (OTOH, for developing against free software operating systems, such an attitude of 'fix the underlying problem first' makes perfect sense).
Who cares if there's a problem with the OS? If you develop for a platform where there is a problem with the OS, you work around that problem.
Sure, if it's a problem that affects many people. It may not make sense to work around a problem that affects just one person. Especially if nobody else can reproduce it and get any idea of how to avoid it.
The thing is that it's not a 'show stopper' for the Mozilla developers. Their job is to find bugs in Mozilla, not to help you personally. If you benefit from the investigation of a bug that is a side effect.
In this case, there is clear proof that there is a bug in the operating system that needs to be fixed, and until it is there is little point trying to debug Mozilla. If you think otherwise you should explain why you think your bug (which cannot be reproduced by anyone else and is certainly due to a fault in the OS) should be prioritized above the thousands of other bug reports which are for definite faults in the Mozilla code and come with instructions to reproduce, test cases or patches.
If you want support, I am afraid you need to pay for it: the Mozilla bug tracker does not exist to provide support to end users. OTOH, if you will help with investigation of a bug and provide the developers with the information they need, they will usually look into it. If you just harangue the developers about a bug in someone else's operating system you are not likely to get anywhere.
If the Mozilla developer had been sitting next door to you he or she could have come over and witnessed the crash, and maybe done something (although to my mind 'something' is most likely to be sending a good report to the operating system's developer). But from halfway round the world, with only a report of 'my PC crashes when Mozilla runs', it is almost impossible to do anything. So it is understandable that they choose to focus on bug reports which show things that are definitely Mozilla bugs (whereas yours _could_ be a bug in Mozilla, but is definitely an OS bug too).
So essentially it's this assertion of 'if anybody involved had made a modest effort they would have found it' - this really is not possible when you can't reproduce the bug. In such cases, you are the only person with access to the hardware and setup that breaks, so rightly or wrongly it is down to you to make the modest effort.
*For you* Mozilla was the application that triggered the OS bug, that does not mean that it was Mozilla's fault. There may well have been a memory leak in Mozilla, however your report that your system crashes does absolutely nothing to help the Mozilla developers debug this. I don't mean to belittle the problem but the sad fact is that a report of 'my particular PC crashes' is of no use to the application developer, unless it's a program that does hardware access or exotic device driver access. It might, however, be helpful to the author of the operating system or device driver, who will have access to the same hardware and may be able to download the application and reproduce the crash.
I have to ask, in all the time you spent asking the Mozilla developers about this problem, did you do anything to report it to the vendor of the operating system or device drivers you are using?
"Bug in the graphics driver or Windows' graphics subsytem is rather irrelevant" - no, the bug is in the operating system. It is not irrelevant.
I'm glad that you were able to stop triggering the OS bug by changing to a newer version of Mozilla, one that is less memory-hungry. I am sure there are many bugs that were fixed in Mozilla that stopped it stressing the system so much. But this means that a chance of fixing the real, underlying bug is lost. It may still exist and be biting some other user running a different application.
You have a too low opinion of Windows 2000 and an operating system's job. If the machine crashes this indicates either faulty hardware, or faulty operating system (including device drivers). Always.
Mozilla people here and on Bugzilla constantly told me it wasn't Mozilla and that it was impossible for an application to crash Windows 2000
This is quite right. Well, it's not impossible as you have found, but if it happens it indicates a bug in Windows 2000 or in some device driver. There may be a bug in Mozilla too - but the bug in the operating system or driver is much more serious and should be addressed first. It will probably be much easier to find the bug in Mozilla, if there is one, once the OS or driver bug is fixed.
Some other examples of the same principle:
'gcc reliably crashes when building this code' => there is a bug in gcc, not your code;
'my web browser crashes when viewing this page' => the fault is with the web browser, not the page;
'my computer crashes when I scroll the mouse wheel in a particular way' => the computer or operating system is faulty, not the mouse.
Slashdot Mirror
In other words: stick to what you know. Let Winzip do the compression and archiving, and let someone else do the encryption. WTF is wrong with making a zipfile and then encrypting it with PGP? The only reasons to put encryption in Winzip itself are fairly bogus arguments about convenience, and the chance to charge more money for a product that does more (even if it does it badly).
I expected that Google would do something more like Gmane and start indexing existing mailing lists. The web search looks at existing pages, it doesn't let you make your own (unless that is coming?). But it looks like they want to make something better than Yahoo Groups, which should not be difficult.
I wonder if they will feed out the groups as NNTP, or as mailing lists which can be fed into Gmane. Then one will be able to read them with a convenient newsreader interface along with everything else.
So what's the relationship between WTL and MFC?
I wonder if this code release could be helpful for those porting MFC or WTL applications to Winelib.
It's 2004. Is there no way to run a program in a sandbox and give it limited privileges by default?
For example, you could run the app with read-only access to the filesystem, and no network access. To prevent noddy DoS attacks the process and its children could be limited to 100 megabytes of memory and ten fork() calls.
Better still, the app could have no access to any file apart from its own program code (ie, the files inside the application directory). If you want to view a file in the application, the file manager program passes it an open file descriptor to read from but only after you have explicitly selected the file in the file manager and asked to view it in the untrustworthy application.
This could also be done for IRC clients, web browsers and other programs where a serious enough bug could open up nasty ways for others to hijack your computer. There's no real reason to run these will full user privelege. They don't need the ability to delete arbitrary files from your home directory, so why do we grant it to them?
I know what bogomips are for, my point is that on a two-CPU system printing the 'total' number of bogomips by adding the two CPUs together is even more bogus ;-P.
The only people using the bonded sender headers will be direct marketers. So surely you want to give the rule a positive score? I'd say +5 or so since such a header is an almost certain indication of spam. (Or if not strictly speaking spam, at least crud.)
(My point is, reprinting inane press releases does nobody any good.)
I'm surprised that the marketing department missed the upcoming opportunity to label dual-core CPUs with 'twice' the clock speed, as is done for bogomips.
Are high-end servers still sold that won't take more than 16Gbyte (I assume you meant 16Gbyte not 16Gb) of RAM?
You have to compare these expensive RAM disks against two alternatives. Firstly, getting a server with a reasonable number of memory slots and loading it up with X gigabytes of memory; secondly, buying a dozen PCs, sticking four gigs of memory in each and having some wacky Gigabit Ethernet, SCSI, or Fibre Channel attachment to turn each one into a RAM disk. Although I expect that the power consumption for a PC would be higher, and it might take more space.
Reviews often mention the distribution's configuration tools. This makes sense, since they're one of relatively few features that really distinguish one distribution from another. But reviews don't normally go into enough depth or try hard enough to see how the distro copes with unusual breakage.
My pet hate is the PPP dialup in Red Hat - it's much too easy to get it into a wedged state by plugging and unplugging the phone line, and the diagnostics printed are very poor if you have something like the wrong PPP password. You can crash the wizard (spewing out Python diagnostics) if you press the Close button on the window at the wrong moment. When things work, it's fine, but when things break it is difficult to recover. These are faults common to many Linux setup wizardy things.
So I think reviewers should really try to mess things up a bit - yank out the Ethernet cable, power-cycle the machine without shutting down, change from one plug-and-play monitor to another and see if the distro correctly reconfigures. Maybe even edit some config files by hand and see if the config wizards can cope - and if they cannot cope, at least give a clean error message.
Reviews tend to give marks for having a long list of features but really it is more important to have a small set of features that are foolproof and rock-solid.
If they want to block porn and save bandwidth, all they need do is not serve images.
To hype anything as 'new' and 'revolutionary' is silly, since as we all know, nothing new has been invented since 1970. But there are certainly techniques which aren't as popular as they deserve to be. One is Delta Debugging as implemented by delta (a tool to automatically produce minimal test cases) and Ask Igor.
Nine out of ten businesses using free software isn't a big deal. A better milestone would be when only nine out of ten, or fewer, are using proprietary software.
The fact that MySQL customers have not felt the need for stored procedures does not imply that they are 'just bloat' which is what you said. Note that MySQL customers are a self-selecting set of people who don't consider stored procedures (and to some extent, other RDBMS features like views, subqueries and high-concurrency ACID) to be that important. On the other hand, Oracle customers are self-selecting as people who do want that kind of thing and are willing to pay for it, so it might not be fair to judge MySQL on the basis of what Oracle customers want either. But when almost every other RDBMS supports these things, you see that MySQL is the odd one out, not Oracle.
DOS (specifically DR-DOS) still sells in some numbers, and DOS customers are not (on the whole) clamouring for lightweight threads or a journalling filesystem or multiuser security. This does not mean that these are not important features for most other operating systems. To say that DOS customers haven't been asking for them does not change the fact that they are highly valued for most of the rest of the world.
About the 'gotchas' - extensions to ANSI SQL is fine, but my feeling is that if I declare a column as 'int not null', I expect the value to be not null. No ifs, no buts. An 'extension' to the SQL semantics where the column can get populated with null values in certain odd cases and with no warning is very surprising and even dangerous. Almost any deviation from standards (indeed, any bug) can be counted as an 'extension' if you look at it the right way. The best thing would be for MySQL to have a standard mode and an extended mode; then these extra 'features' could be turned on or off depending on their merits.
You may be right that the people who want features like subqueries, views or stored procedures are not providing reasons but only whining. On the other hand, you are guilty of the same thing with blanket statements like 'Stored procedures and similar features are just bloat, and gain you no real advantage' - many programmers working with more advanced RDBMSes know otherwise. BTW, I also disagree with your assertion about subqueries being slow: you have to take care, yes, but like most things they are a very useful tool in the right hands and most simple uses of subqueries are not slow (at least on the databases I have most used, Oracle and Sybase).
I'm interested to know: have you ever run into the problems mentioned in MySQL Gotchas? Or are these deviations from the ANSI standards something that doesn't matter in practice.
You're right; I was thinking only of serializability (isolation of transactions) and not about durability or atomicity. Okay then: you could easily keep two copies of the database, perform the transaction on one, and if it succeeds copy all the data over to the other copy. If the transaction fails part way through you roll back from the other copy. You make sure disk buffers are flushed before performing the copy over. This takes care of both atomicity and durability. Again, it's not difficult to do: the challenge is in doing it and keeping performance.
A database benchmark of how fast you can perform a million insert statements is pretty meaningless: what matters (for large applications, anyway) is how fast you can serve a large number of clients in parallel, all performing updates, while preserving transactional integrity and never losing any data if the power cord is yanked. Any claim that database A is faster than database B should be taken with a pinch of salt unless you can be sure they are providing the same level of ACID guarantees.
The LUGs can and should be the trustees or guardians that trust. Who else is going to do it? IBM? Novell?
That's why I think the LUGs have to expand their outlook to take in questions of the war and the military use of Linux.
Uh, yeah. That makes perfect sense.
It might have helped if he gave some suggestion of what the LUGs might _do_ about these questions, after all Linux (and even the GNU project) has always been about doing rather than posturing.
The reason for its success: Worse is better.
What you say about disregard for SQL standards is true, see MySQL Gotchas. Doing the wrong thing is not so bad, it's *silently* doing the wrong thing that you absoultely do not want in a database system. See also Why not MySQL, which is now rather dated (MySQL has grown some features since), but is a good introduction to what a database should do.
Note also that anyone can write a database system with complete transactional integrity: you simply lock the whole database for every single operation and run only one query or update at a time, one after the other. The challenge is in getting the semantics of serialized database access but with good performance. This is what schemes like row-level locking and multi-version concurrency are for.
I thought that the crash being referred to earlier in this discussion was a hard failure of the OS. Also I didn't take into account that on WinDOS everything runs with full user privs. I was assuming Windows 2000 or some other NT-based system. I certainly would consider it a bug if any non-privileged executable could hard lock up an NT system for any reason (though it has been known, of course).
Likewise if you can bring down the X server by sending it bad requests (this is perhaps a closer analogy). But I'll admit that for code running in a privileged enough user account (eg local administrator rights on a Windows box) it is possible to do bad things without exploiting an OS bug.
Well - why didn't you say so? From everything you said so far I assumed you had some bug that only crashed your machine and nobody else's. However, there is still a bug in the OS and in an ideal world that would be fixed _first_. The Moz developers may be acting too idealistic in this respect (OTOH, for developing against free software operating systems, such an attitude of 'fix the underlying problem first' makes perfect sense).
The thing is that it's not a 'show stopper' for the Mozilla developers. Their job is to find bugs in Mozilla, not to help you personally. If you benefit from the investigation of a bug that is a side effect.
In this case, there is clear proof that there is a bug in the operating system that needs to be fixed, and until it is there is little point trying to debug Mozilla. If you think otherwise you should explain why you think your bug (which cannot be reproduced by anyone else and is certainly due to a fault in the OS) should be prioritized above the thousands of other bug reports which are for definite faults in the Mozilla code and come with instructions to reproduce, test cases or patches.
If you want support, I am afraid you need to pay for it: the Mozilla bug tracker does not exist to provide support to end users. OTOH, if you will help with investigation of a bug and provide the developers with the information they need, they will usually look into it. If you just harangue the developers about a bug in someone else's operating system you are not likely to get anywhere.
If the Mozilla developer had been sitting next door to you he or she could have come over and witnessed the crash, and maybe done something (although to my mind 'something' is most likely to be sending a good report to the operating system's developer). But from halfway round the world, with only a report of 'my PC crashes when Mozilla runs', it is almost impossible to do anything. So it is understandable that they choose to focus on bug reports which show things that are definitely Mozilla bugs (whereas yours _could_ be a bug in Mozilla, but is definitely an OS bug too).
So essentially it's this assertion of 'if anybody involved had made a modest effort they would have found it' - this really is not possible when you can't reproduce the bug. In such cases, you are the only person with access to the hardware and setup that breaks, so rightly or wrongly it is down to you to make the modest effort.
*For you* Mozilla was the application that triggered the OS bug, that does not mean that it was Mozilla's fault. There may well have been a memory leak in Mozilla, however your report that your system crashes does absolutely nothing to help the Mozilla developers debug this. I don't mean to belittle the problem but the sad fact is that a report of 'my particular PC crashes' is of no use to the application developer, unless it's a program that does hardware access or exotic device driver access. It might, however, be helpful to the author of the operating system or device driver, who will have access to the same hardware and may be able to download the application and reproduce the crash.
I have to ask, in all the time you spent asking the Mozilla developers about this problem, did you do anything to report it to the vendor of the operating system or device drivers you are using?
"Bug in the graphics driver or Windows' graphics subsytem is rather irrelevant" - no, the bug is in the operating system. It is not irrelevant.
I'm glad that you were able to stop triggering the OS bug by changing to a newer version of Mozilla, one that is less memory-hungry. I am sure there are many bugs that were fixed in Mozilla that stopped it stressing the system so much. But this means that a chance of fixing the real, underlying bug is lost. It may still exist and be biting some other user running a different application.
You have a too low opinion of Windows 2000 and an operating system's job. If the machine crashes this indicates either faulty hardware, or faulty operating system (including device drivers). Always.
Some other examples of the same principle:
'gcc reliably crashes when building this code' => there is a bug in gcc, not your code;
'my web browser crashes when viewing this page' => the fault is with the web browser, not the page;
'my computer crashes when I scroll the mouse wheel in a particular way' => the computer or operating system is faulty, not the mouse.