Do you think you can just "reconfigure" Apache to beat thttpd?
This is a bad analogy. Apache-httpd is never faster than say lighttpd, it is mearly the default... and some argue fast/good enough for a significant number of "normal" cases (and even more would agree when combined with things like varnish).
If we needed more speed in web servers noone would be using Apache-httpd.
The GNU project was founded in 1984 to create a free operating system.
Ok, true enough.
In 1991, they were almost completely finished - they had written every essential component of a Unix-like operating system except for a kernel.
Sure, and I've almost created a free engery device... I've done everything apart from this one bit that creates energy for free. Also, GNU did not "create" everything else apart from the kernel... they created some pieces and were doing the distribution work, so other people "donated" their work.
Linus came along, wrote the Linux kernel,
True enough.
combined it with the almost-complete GNU system, and called the whole thing Linux.
Not even close to true, Linux has only ever distributed the kernel... other people combined it and called the whole things like "Red Hat Linux" or "Slackware Linux", GNU should/could have done this but had not bothered to do the work to make a usable distribution (as more than a collection of tarballs) and were happily ignoring Linux and telling everyone else to ignore it and use GNU-Hurd when it would be ready "any time now". This was pretty obvious naming at the time, we didn't call Solaris "GNU/Solaris" when we installed GCC, GNU-tar etc. on it.
The GNU people were rightly upset that they were getting no credit for their work (to build a complete Unix-like OS).
They got a huge amount of credit, for the work they did. They just didn't get their name in lights... because they refused to do the work required for that. Then they complained and wanted more recognition than anyone else got who'd done the same amount of work as they had (like Perl or Xorg etc.)... this created a "slight" backlash by people who actually know what happened.
As such it works much better to have the rules more simple and open ended. Basically "Don't be a dick." Though they may pretend they don't know what you mean, they do and it works.
See the big difference is that you can't automatically get a computer to scan for people "being a dick"... but getting a computer to count the number of bytes you use is the easiest thing in the world. Also they are advertising "unlimited bandwidth". When running forums you didn't advertise "say what you want postings"
If they just: 1) Stopped saying it was unlimited, when it isn't. 2) Actually implemented the limiting using a rolling average or something (possibly even taking into account where your data is coming from, and what time it is etc.).... no one sane would care, in fact I'd be telling everyone that they had a great service. As it is, I'm happy to point to this kind of information and tell people that comcast are lying cheating scum and noone should even think of using them.
I have no problems at all with not for profit entities using some of my bandwidth to distribute their files.
I have serious problems with a for profit entity like Microsoft or Redhat doing the same.
The first one I call "charity" or "support". The second one I call "leaching", and its not far from "stealing".
If you're a for profit company and you can't afford bandwidth, then you need to find a new line of work.
As with most things, I don't think you want to put this as a black or white choice. For instance, I could easily see a future where you pay $Y per. year and agree to some P2P like activity or you pay $Y x 10 (or whatever) and you download all data via. "priority" HTTP channels.
From what I've seen providers of large amounts of content are paying huge bandwidth bills, so it seems like an obvious solution to charge directly for your biggest expense... esp. when it's very likely a large portion of your customers won't miss say 10KB/s, and will be happy to download from 500-1,000 other customers.
As with advertising though, I think there will be a sweet spot for what people will accept after which they'll be reluctant to participate at all. And I'm not sure that some of the people thinking of doing this know that, so in 5-10 years we might well be back to where we are today in how data is transfered.
While I agree that having to do print("Hello world") instead of print "Hello world" is going to be painful (tm), I can't help but feel that it might be worth it if only so that print won't have the horribly ugly warts on the language it does now.
"print >>os.stderr, 'foo'" has to be the ugliest thing in the language, and "print 'foo'," is probably second.
Of course I don't think they needed to sacrifice backwards compat. to add the new syntax, but given an either or choice I'd probably go for breaking everything... but then I'd also choose brackets, so I'm probably given a minus vote for making Python decisions:)
Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.
Many? Debian (and "inherited" distros. like Ubuntu) does. Fedora doesn't (and "inherited" distros. like CentOS) doesn't. Is that common on win32, on FreeBSD? I didn't think so. Also saying "just use update-alternatives" to change your system Python is insanity IMNSHO, either you are using it and doing the above will almost certainly break something... or you aren't and should just stick with the default. Note that I'm not saying having a/usr/bin/python-2.3 isn't useful, just that changing what/usr/bin/python points to is a very bad idea.
And before this turns into a flamewar against Fedora, my bet is that the major reason Fedora don't allow different version of Python and Debian do is that Fedora has a huge amount of "core" code written in Python while Debian have almost none.
I used to prefer Excel in the days when I did large spreadsheets
So this confuses me, one of the useful things MS did while adding the "ribbon" was to up the spreadsheet limits to reasonable values (circa. gnumeric 1999 or so). Before that it was "common" knowledge that you couldn't open multi-MB CSV files in excel because it would chop the data.
Personally I think it's much more likely, at least initially, that they'll go the hybrid route. So you'll have say 10GB of SS and 1TB of "traditional" drive. But then it's also not obvious at the moment when the market will stop caring about larger amounts of storage, for instance it's possible that if they could do a cheap 20-40GB SSD that would work at the low end.
I have to disagree with you. Contracts should not be banned. Some people even like those. They can get a new phone every couple years without paying a lot up front. These are the same people that lease cars and trade up every 2 or 3 years.
People like paying a small monthly fee instead of a single "large" payment, News at 11. Leasing a car is a pretty bad analogy for a start most people don't get them that way, opting for 3-6 year loans (an option not really available with cell phones). This is more like the "gas" companies selling the gas and the cars, and subsidizing the later by large overheads on the former... and if they tried that it would be stopped immediately due to illegally tying of products.
On the other hand, all the telcos are thieving scum... so even if they "fixed" this tying problem they'd all still screw everyone over.
My criteria are usability, utility, and functionality.
Except that memory footprint is not unconnected with your criteria. Bloated software is slower to load, more complicated to use, and a pain to maintain. Worst of all, it tends to have lots of bugs caused by feature creep and conflict between its many modules.
[...]
Of course, "tiny app" enthusiasts go beyond eliminating bloat; they're in love with the challenge of eliminating extra bytes just for its own sake. But even their work adds a lot utility, especially if you're the kind of user who prefers obscure command line idioms and considers GUIs too clumsy.
Right, when something is "too bloated" I'd just mark it down as unusable, or at least less usable. One of the big problems I see is that the "tiny app" people tend to produce unusable crap, and then think they've done something useful because it's only 2K or whatever.
Dietlibc is a good example, as with most people I'd be very happy with an alternative to GLibc esp. if that was smaller and faster for "simple" apps. (Ie. non-threaded, not using expensive interfaces like POSIX aio etc.)... but dietlibc is an exercise in how badly they can reimplement the C std. library and get away with it (but, hey, it's small). The result is completely useless.
This generally results in me (and I suspect a lot of other people) not talking about "bloated" at all anymore, as I don't want to be associated with the "tiny app." nut jobs, even though minimal size (but no smaller) is something I strive for in my code.
And GNU is, love it or hate it, thousands of great applications; and moreover a licence accepted by the majority of FOSS developers.
I hope(d) Ian would have the power to apt-ing Solaris, but he doesn't seem to. And when you read the OpenSolaris lists, you find as much ego-tripping as on OpenBSD or Mac. They rather sink with pkgadd.
And I cry for them, yes, because SunOS is the greatest kernel around, with limited hardware support.
That's the biggest problem for Sun with Solaris, everyone bases their opinion of it (good and bad) from about 10 years ago (because that was the last time anyone used it). Certainly the newer Solaris kernel has some nice properties, ZFS and DTrace among them and in many ways it would be nice if it could complete on a level playing field and the users would then get the best of all worlds. But this is like wishing for the same thing from DragonflyBSD etc.... you have to take a bundle and the entire bundle is not nearly so nice. Solaris is and has been a loser to Linux networking and CPU scalability (both up and down) for some time now, the userspace in Solaris is still horrible (as you said package management being especially painful) and some Solaris engineers are still proud of that.
Then as others have pointed out, you add to all of those major technical problems all the political ones like the fact that they still don't have an OSI "OpenSolaris", CDDL isn't compatible with existing licenses etc.... but even if they fixed all of their political problems (prob. roughly 0) it's still not going to be a significant challenge, without a lot of technical fixes, IMO
When you write a new software application, your expenses are things like compiler licenses, printer paper, etc.... The true cost of development is in paying your software developers.
If your staff aren't an expense, what are they? Liabilities?;)... I would have assumed that the 8 million expense covered everyone's time, but as Twitter said getting a 10x ROI on this kind of thing probably isn't that terrible.
Riiight, so they post all of his work and that's "fair use" and he posts an except from theirs (probably the majority of which he owned the copyright to) and that's "not fair use". I think you might have that backwards.
That's way too harsh, for the RHCE anyway. While I wouldn't hire someone just because they got an RHCE, I would certainly not hire someone if they failed it (as the only people I've seen who failed it were clueless in real life).
Some of that might be due to the significant portion of the RHCE that is practical "this is broken fix it" or "this box needs to X, Y and Z... make it happen".
There is a file on my drive, and I want to find out when it was created, just out of curiosity?
But you downloaded it from a website, deleted it and restored it from backup, copied to a USB stick and back (to take it somewhere else and edit) or emailed it to yourself from work... and you forgot. So you know you've had it for at least 3-4 years and the "creation date" says 18 months ago.
The problem with NO comments is that debugging can not determine wither code is correct - it can only find whether two representations of a solution are equivalent.
...
So a good programmer writes TWO versions of his program - in representations as different as possible. (Preferably one optimized for automated translation, one for human readability.) That way he's thinking in different mindsets, greatly reducing the likelihood of making identical errors in both representations
Who cares about identical errors, you're screwed either way then. The big problem is when the "documentation" and the "code" don't match... you have no idea which one is wrong.
As the old saying goes: "The man who has a watch knows what time it is, the man who has two is never sure."... of course the man who has one watch and a big pile of unit tests which prove it's keeping the right time is doing the best of all:).
I've been at this for a pretty long time now, and I've found very little use for "comments explaining what the code does"... but a lot of use for "comments explaining why". And personally, I've gone back to code I've written over 5 years ago and could see what it was doing instantly... and on the bad side I've read code I wrote a year or so ago and not understood why it was doing something (to be fair, after thinking about it a bit it became "obvious"... but then I wrote a comment explaining it anyway:).
Yes, I've read others peoples code that (in theory) would have been easier to understand if it had been heavily commented... but it would have been even easier to read if they'd just been any good at what they were doing and written the code well.
Until such a time as people stop using baseless lawsuits to get their way, zero tolerance policies will rule the day
I'd say the probability of that is roughly 0, but there's another way... allow significant lawsuits for people screwed over by baseless zero tolerance policies.
Why do you think two schedulers is better than one? I think that better design should meld the two positive aspects into one algorithm, instead of having two different areas to look for and fix bugs
Let's take an example that has enough people pushing for it with money, the I/O scheduler. That is completely pluggable, with three or four different versions that are each very useful in different cases... and the default is still pretty good "in the average case".
As for just make one good one one of the I/O schedulers is "do nothing at all, to save CPU" and then another one is "burn huge amounts of CPU to save seek time". Merging these two scheduler strategies into one would be impossible.
Lest you think that's an isolated incident, consider that with the "recent" TCP_CONGESTION sockopt you can now basically change your TCP scheduler per. network connection.
IMO there's nothing wrong with sending tapes home with people.
Sure, I've worked at places that do that... but sending them home with the intern? Whenever I've seen it done it's been with trusted full time employees, with a paper trail of exact what went to their home.
Probably although, personally, I wouldn't bet that much on it. I'm pretty sure the above "works" on glibc at least in the normal cases... but there are a significant number of non-normal cases, and I'd be worried that libc would change the internal copy to a memcpy() and I'd be screwed or that GCC would do something "intelligent" (esp. given that ISO 9899:199 defines sprintf as having a restrict'd pointer for the first two arguments). At the very least I wouldn't be surprised to see GCC complain about it.
A significant number of people thought C compilers would never care about aliasing, but they do now.
Fair enough, I'm not talking about you then:). I'd heard that it was "designed" for using in copying directory names to user space in Unix... where the name was a fixed size string, that might not be terminated if it used all 15 characters (and you don't want information leaks if it's less than that). So I should probably have said: usage of strncpy(), as a normal string API, almost certainly guarantees you have bugs...
As someone who's written 2 pieces of OSS with 100% code coverage in unit tests, and probably the most secure C http server (comes with over 75% coverage). I have to say: "It's not quite that simple". Testing does not negate design, and designing for security is non-trivial and takes a certain mind-set... and while a lot of people say they want security, almost none are actually prepared to buy it (with either money, lack of features, whatever).
Hell, one of the biggest advancements in security in recent years is SELinux, and I see almost nothing but complaints about how it "is less usable, so we just turn it off". Summary: We are still dealing with security problems because that's what the majority of the market wants, welcome to democracy and the free market.
strncpy(), not strcpy()!
Actually usage of strncpy() almost certainly guarantees you have bugs, IMNSHO. You need a real managed string API. Assuming the programer can keep track of three distinct pieces of information like "size, length and pointer" is just a losing bet. All of the applications (including mine) that have had security guarantees with money have internally used a real managed string API.
Slashdot Mirror
This is a bad analogy. Apache-httpd is never faster than say lighttpd, it is mearly the default ... and some argue fast/good enough for a significant number of "normal" cases (and even more would agree when combined with things like varnish).
If we needed more speed in web servers noone would be using Apache-httpd.
Better idea, let's just get history correct.
Ok, true enough.
Sure, and I've almost created a free engery device ... I've done everything apart from this one bit that creates energy for free. Also, GNU did not "create" everything else apart from the kernel ... they created some pieces and were doing the distribution work, so other people "donated" their work.
True enough.
Not even close to true, Linux has only ever distributed the kernel ... other people combined it and called the whole things like "Red Hat Linux" or "Slackware Linux", GNU should/could have done this but had not bothered to do the work to make a usable distribution (as more than a collection of tarballs) and were happily ignoring Linux and telling everyone else to ignore it and use GNU-Hurd when it would be ready "any time now". This was pretty obvious naming at the time, we didn't call Solaris "GNU/Solaris" when we installed GCC, GNU-tar etc. on it.
They got a huge amount of credit, for the work they did. They just didn't get their name in lights ... because they refused to do the work required for that. Then they complained and wanted more recognition than anyone else got who'd done the same amount of work as they had (like Perl or Xorg etc.) ... this created a "slight" backlash by people who actually know what happened.
See the big difference is that you can't automatically get a computer to scan for people "being a dick" ... but getting a computer to count the number of bytes you use is the easiest thing in the world. Also they are advertising "unlimited bandwidth". When running forums you didn't advertise "say what you want postings"
If they just: 1) Stopped saying it was unlimited, when it isn't. 2) Actually implemented the limiting using a rolling average or something (possibly even taking into account where your data is coming from, and what time it is etc.). ... no one sane would care, in fact I'd be telling everyone that they had a great service. As it is, I'm happy to point to this kind of information and tell people that comcast are lying cheating scum and noone should even think of using them.
I have serious problems with a for profit entity like Microsoft or Redhat doing the same.
The first one I call "charity" or "support". The second one I call "leaching", and its not far from "stealing".
If you're a for profit company and you can't afford bandwidth, then you need to find a new line of work.
As with most things, I don't think you want to put this as a black or white choice. For instance, I could easily see a future where you pay $Y per. year and agree to some P2P like activity or you pay $Y x 10 (or whatever) and you download all data via. "priority" HTTP channels.
From what I've seen providers of large amounts of content are paying huge bandwidth bills, so it seems like an obvious solution to charge directly for your biggest expense ... esp. when it's very likely a large portion of your customers won't miss say 10KB/s, and will be happy to download from 500-1,000 other customers.
As with advertising though, I think there will be a sweet spot for what people will accept after which they'll be reluctant to participate at all. And I'm not sure that some of the people thinking of doing this know that, so in 5-10 years we might well be back to where we are today in how data is transfered.
While I agree that having to do print("Hello world") instead of print "Hello world" is going to be painful (tm), I can't help but feel that it might be worth it if only so that print won't have the horribly ugly warts on the language it does now.
"print >>os.stderr, 'foo'" has to be the ugliest thing in the language, and "print 'foo'," is probably second.
Of course I don't think they needed to sacrifice backwards compat. to add the new syntax, but given an either or choice I'd probably go for breaking everything ... but then I'd also choose brackets, so I'm probably given a minus vote for making Python decisions :)
Many? Debian (and "inherited" distros. like Ubuntu) does. Fedora doesn't (and "inherited" distros. like CentOS) doesn't. Is that common on win32, on FreeBSD? I didn't think so. Also saying "just use update-alternatives" to change your system Python is insanity IMNSHO, either you are using it and doing the above will almost certainly break something ... or you aren't and should just stick with the default. Note that I'm not saying having a /usr/bin/python-2.3 isn't useful, just that changing what /usr/bin/python points to is a very bad idea.
And before this turns into a flamewar against Fedora, my bet is that the major reason Fedora don't allow different version of Python and Debian do is that Fedora has a huge amount of "core" code written in Python while Debian have almost none.
So this confuses me, one of the useful things MS did while adding the "ribbon" was to up the spreadsheet limits to reasonable values (circa. gnumeric 1999 or so). Before that it was "common" knowledge that you couldn't open multi-MB CSV files in excel because it would chop the data.
Maybe you have a different definition or large?
Personally I think it's much more likely, at least initially, that they'll go the hybrid route. So you'll have say 10GB of SS and 1TB of "traditional" drive. But then it's also not obvious at the moment when the market will stop caring about larger amounts of storage, for instance it's possible that if they could do a cheap 20-40GB SSD that would work at the low end.
I type make, and it tells me where all the errors are. This is one of the things I dislike about python etc. ... typos become a runtime error, *sigh*.
People like paying a small monthly fee instead of a single "large" payment, News at 11. Leasing a car is a pretty bad analogy for a start most people don't get them that way, opting for 3-6 year loans (an option not really available with cell phones). This is more like the "gas" companies selling the gas and the cars, and subsidizing the later by large overheads on the former ... and if they tried that it would be stopped immediately due to illegally tying of products.
On the other hand, all the telcos are thieving scum ... so even if they "fixed" this tying problem they'd all still screw everyone over.
Right, when something is "too bloated" I'd just mark it down as unusable, or at least less usable. One of the big problems I see is that the "tiny app" people tend to produce unusable crap, and then think they've done something useful because it's only 2K or whatever.
Dietlibc is a good example, as with most people I'd be very happy with an alternative to GLibc esp. if that was smaller and faster for "simple" apps. (Ie. non-threaded, not using expensive interfaces like POSIX aio etc.) ... but dietlibc is an exercise in how badly they can reimplement the C std. library and get away with it (but, hey, it's small). The result is completely useless.
This generally results in me (and I suspect a lot of other people) not talking about "bloated" at all anymore, as I don't want to be associated with the "tiny app." nut jobs, even though minimal size (but no smaller) is something I strive for in my code.
Galeon wasn't an option, why?
That's the biggest problem for Sun with Solaris, everyone bases their opinion of it (good and bad) from about 10 years ago (because that was the last time anyone used it). Certainly the newer Solaris kernel has some nice properties, ZFS and DTrace among them and in many ways it would be nice if it could complete on a level playing field and the users would then get the best of all worlds. But this is like wishing for the same thing from DragonflyBSD etc. ... you have to take a bundle and the entire bundle is not nearly so nice. Solaris is and has been a loser to Linux networking and CPU scalability (both up and down) for some time now, the userspace in Solaris is still horrible (as you said package management being especially painful) and some Solaris engineers are still proud of that.
Then as others have pointed out, you add to all of those major technical problems all the political ones like the fact that they still don't have an OSI "OpenSolaris", CDDL isn't compatible with existing licenses etc. ... but even if they fixed all of their political problems (prob. roughly 0) it's still not going to be a significant challenge, without a lot of technical fixes, IMO
If your staff aren't an expense, what are they? Liabilities?;) ... I would have assumed that the 8 million expense covered everyone's time, but as Twitter said getting a 10x ROI on this kind of thing probably isn't that terrible.
Riiight, so they post all of his work and that's "fair use" and he posts an except from theirs (probably the majority of which he owned the copyright to) and that's "not fair use". I think you might have that backwards.
Note that this just moves who the IRS goes after for the money, the IRS isn't that stupid and knows that $1 isn't the fair market value for the car.
That's way too harsh, for the RHCE anyway. While I wouldn't hire someone just because they got an RHCE, I would certainly not hire someone if they failed it (as the only people I've seen who failed it were clueless in real life).
Some of that might be due to the significant portion of the RHCE that is practical "this is broken fix it" or "this box needs to X, Y and Z ... make it happen".
But you downloaded it from a website, deleted it and restored it from backup, copied to a USB stick and back (to take it somewhere else and edit) or emailed it to yourself from work ... and you forgot. So you know you've had it for at least 3-4 years and the "creation date" says 18 months ago.
Sounds like a great feature.
Who cares about identical errors, you're screwed either way then. The big problem is when the "documentation" and the "code" don't match ... you have no idea which one is wrong.
As the old saying goes: "The man who has a watch knows what time it is, the man who has two is never sure." ... of course the man who has one watch and a big pile of unit tests which prove it's keeping the right time is doing the best of all :).
I've been at this for a pretty long time now, and I've found very little use for "comments explaining what the code does" ... but a lot of use for "comments explaining why". And personally, I've gone back to code I've written over 5 years ago and could see what it was doing instantly ... and on the bad side I've read code I wrote a year or so ago and not understood why it was doing something (to be fair, after thinking about it a bit it became "obvious" ... but then I wrote a comment explaining it anyway :).
Yes, I've read others peoples code that (in theory) would have been easier to understand if it had been heavily commented ... but it would have been even easier to read if they'd just been any good at what they were doing and written the code well.
I'd say the probability of that is roughly 0, but there's another way ... allow significant lawsuits for people screwed over by baseless zero tolerance policies.
Let's take an example that has enough people pushing for it with money, the I/O scheduler. That is completely pluggable, with three or four different versions that are each very useful in different cases ... and the default is still pretty good "in the average case".
As for just make one good one one of the I/O schedulers is "do nothing at all, to save CPU" and then another one is "burn huge amounts of CPU to save seek time". Merging these two scheduler strategies into one would be impossible.
Lest you think that's an isolated incident, consider that with the "recent" TCP_CONGESTION sockopt you can now basically change your TCP scheduler per. network connection.
Sure, I've worked at places that do that ... but sending them home with the intern? Whenever I've seen it done it's been with trusted full time employees, with a paper trail of exact what went to their home.
Probably although, personally, I wouldn't bet that much on it. I'm pretty sure the above "works" on glibc at least in the normal cases ... but there are a significant number of non-normal cases, and I'd be worried that libc would change the internal copy to a memcpy() and I'd be screwed or that GCC would do something "intelligent" (esp. given that ISO 9899:199 defines sprintf as having a restrict'd pointer for the first two arguments). At the very least I wouldn't be surprised to see GCC complain about it.
A significant number of people thought C compilers would never care about aliasing, but they do now.
Fair enough, I'm not talking about you then :). I'd heard that it was "designed" for using in copying directory names to user space in Unix ... where the name was a fixed size string, that might not be terminated if it used all 15 characters (and you don't want information leaks if it's less than that). So I should probably have said: usage of strncpy(), as a normal string API, almost certainly guarantees you have bugs...
As someone who's written 2 pieces of OSS with 100% code coverage in unit tests, and probably the most secure C http server (comes with over 75% coverage). I have to say: "It's not quite that simple". Testing does not negate design, and designing for security is non-trivial and takes a certain mind-set ... and while a lot of people say they want security, almost none are actually prepared to buy it (with either money, lack of features, whatever).
Hell, one of the biggest advancements in security in recent years is SELinux, and I see almost nothing but complaints about how it "is less usable, so we just turn it off". Summary: We are still dealing with security problems because that's what the majority of the market wants, welcome to democracy and the free market.
Actually usage of strncpy() almost certainly guarantees you have bugs, IMNSHO. You need a real managed string API. Assuming the programer can keep track of three distinct pieces of information like "size, length and pointer" is just a losing bet. All of the applications (including mine) that have had security guarantees with money have internally used a real managed string API.