I don't normally participate in this sort of debate but.. you have never needed to calculate the volume of anything? And wouldn't that result in a conversion between something like cubic inches and gallons? Just curious.
In my opinion the metric has two advantages, one big, and one somewhat smaller. The big one is that is a standard... a meter is a meter everywhere, while a pint might or might not more than 0.5 liters. The other being that doing rough estimates in your head is much easier if the conversions are easy (to do and remember). The (smallish) disadvantage is the occasional silly big or small unit, like Tesla (big!) and Pa (small!).
You touch upon that strange thing in western society (or perhaps everywhere, I am not sure). Why is seeing sex considered so harmful to children, compared to quite disgusting violence (that can and will give nightmares, etc)? I have a hard time seeing how seeing sex could really harm a human child... especially such a short exposure such as this. I mean, many children must at least have walked in on their parents having sex at some point... and I think most of those children turn out ok anyway. And I'd wager any healthy boy (and girl more likely than not) have seen some kind of porn at 10 year old (and said "ewwww", too).
I just don't see the reasoning there. Anyone know why or how this "sex is harmful to see for children" came about?
Just to point this out: 10+ years ago, our dear scientist created models that predicted a correspondence between CO_2 and the temperature. In the meanwhile, the CO_2 has been steadily increasing, and the temperature likewise. The temperature has been evolving like the models said it would given the evolution in the earths atmosphere --- not just the trend, but the exact temperatures. That is a pretty good test of the theory validity. I has me convinced at least. If I had any money, I'd invest in companies doing ditches and dams:/
You, sir, sound scaringly like me. Must be a mathematician thing. I am far more at home with octave than openoffice, and I'd have a much easier time writing an xml table and style it with xstl+css than do the same in kspread or any other spreadsheet:)
I see I will get nowhere with this. My example string contained abitrary SQL, not a single table name, and anyway, the table names were of an unknown max length (I see I should have used the classed path length, since that one is well known to be of unknowable length.). Also, the spaces were supposed to go in front, I didn't think I needed to spell that out.
strncpy is not meant for general string manipulation, but for putting strings into a record format which is rarely used these days... at least I have not seen it for more than 10 years.
But as you seem to think that anyone not agreeing with you must be an idiot, I am only writing this in case a novice programmer stumbles upon our, eh, conversation and makes that very common mistake about strlcpy. To recap: In the general case, strlcpy is wrong and non-standard, where another function could achieve at least one of those 2. That's 2 good reasons to avoid it.
That it is also a BSD'ism is the fact that got lost somewhere in this thread.
A few points, the rest of your post speaks for itself.
As for Linus's opinion, anyone can read it in the linked post. He is against the inclusion in glibc and states that very clearly in that thread, for the reasons I have outlined.
First of all, in your example case you would know the max length of table names, and so you would use that instead of 51 as your buffer size. Second, in a case where truncation matters, you test for it, duh?
Until the next someone uses some sort of valid filler (like a spaces, or something else) to achieve that chopoff. Boom, security breach. Yeah, I should've checked the return value, but what then would I have done? Raised an error? Reallocated? The code would end up being even uglier. And we all know that requiring developers to check return codes all the time instead of just doing the right thing is a bound to lead to bugs. Which is why C++'s new no longer returns a null pointer if the allocation fails.
The real problem is the usage of a fixed buffers in the first place. str*cpy all encourages using fixed buffers, which is why these people oppose them. We can't get rid of strncpy (without violated the C standard), but we can avoid adding more of these functions, which only gives you a false sense of security. You could read that thread I linked, (not just the random post I linked to yesterday)... it is quite informative.Here it is openSSH's code that is being picked apart.
And I most certainly don't want strncpy. Yeah, I made a typo, forgetting to remove the length while I copied and pasted, so shoot me. I'd get a compile error and remove the extra parameter. The purpose of strncpy and friends is to manipulate records in a database in a certain format; using them for string handling in any other case is insane. You know that, I know that, any C programmer worth his salt knows that, why do you keep bringing strncpy up?
I didn't use strdup since it isn't available on all platforms, and because I wanted to illustrate the general concept (keep track of the length, (re)alloc as necessary. If I was doing this for real, I'd use/write a library, where the stringtype would be something like
struct easy_string { // length of string size_t length; union { char buffer[40]; char* buf_ptr; }; };
Which could be used with library functions to behave correctly in all circumstances. I am sure such an obvious idea is already implemented in some library, though.
PS: Not being rude? What do you call, and I quote,
Wow, talk about full of shit. ? But I commend you latest effort, which is in a nice and sober tone. Thank you for that, I really appreciate it.
I have made no nonsense claims, and even if I had, you have no reason to be rude.
For Linus's stand on the issue, please read a post he made on this issue. In fact, skip the rest of this post and just read that thread, Linus is a much better teacher than I ever will be.
Still reading? ok, you don't need to tell me basics about C or it's standard library.. I know the language quite well. And I happen to agree that including strlcpy and friends with glibc is no great harm, as long as a fat warning is included in it's manpage (as well as all the other str* and even mem* should have) about it's shortcomings. However, you blithely ignore the fact that truncating strings based on length likely covers a bug more effectively than the security problem the buffer overflow is. Yes, you might avoid the easy security problem (buffer overflow) but you might introduce a worse one. Consider the example. I can follow Ulrich
#ifdef BSD_HACK // Woops! Something like // DELETE FROM TABLE_THAT_USER_IS_NOT_ALLOWED_TO_ACCESS_USER_VIEW // might become // DELETE FROM TABLE_THAT_USER_IS_NOT_ALLOWED_TO_ACCESS char input[51]; strlcpy(input, getValidatedSqlFromUser(), sizeof input); #else #ifdef ULRICH // Safe, if cumbersome. const char* sqlFromUser = getValidatedSqlFromUser(); char* input = (char*) MALLOC(strlen(sqlFromUser)+1); if (!input) { abort();} strcpy(input, getValidatedSqlFromUser(), sizeof input); #else char input[51]; // Woops. Could SEGFAULT (if compiler with stack smashing protection), or overflow bufffer if not (security breach) strcpy(input, getValidatedSqlFromUser()); #endif #endif executesql(input);
Now, given that stack smash protection is pretty much default these days, I'd say the BSD version is the worse security risk, or at least, the one that is hardest to detect. Of course, the design of that program is insane (restricting access in application rather than in the db, e.g.), but I think it illustrates the problem with the strlcpy and friend function pretty clearly.
As for the linuxism... I have had little problem working around them. If you have had trouble with doing that, perhaps I can point out that the source code to each and every non-standard function is available, as well as documentation? Yes, they happen, because like it or not, most people prefer a good function over a portable one, and nothing you or I can do will change this. Nor would I, if I could really. Improving the libraries tend to start at the grassroot level.
Finally, I must declare I am tired of your baseless insults, and will only respond to polite posts from this point on. I can accept shit from great programmers that have illustrated their worthiness, but not from someone who obviously still have a lot to learn.
P.S: Ulrich Drepper's code is incorrect (even if ugly) unlike the code you wrote, at least in the general case. So I think it is taken out of context, as I don't see Drepper making that sort of mistake. The only case strlcpy is valid is if you really want to copy & truncate a string. So if strlcpy was renamed to strcptr(dst,src,n), I think it might be accepted. Though it is a relatively rare usecase, and might be better placed in another library. And once we embarm upon that route, we might as well replace the weak stdlib string library with a safer and better dedicated string library. Like C++ have done with the std::string.
Hey, I don't really have a problem with it, and I resent your language. Learn to talk nice, even if disagree, please. My personal opinion, if you care, is that they are poorly designed functions, but so are just about all the str* function (at least, for inclusion in the stdlib), and 2 more won't really hurt. As I said, it is the glibc team (and yes, Ulrich among them) and Linus that spearheaded rejection of that patch. (I found this out via searching the group with google; I'm sure you can do the same since you seem to care so much)
As I recall, the reasons (not my reasons, though I find them reasonably sounds) were:
they are unneccessary (as you should always keep track of how long your string is and realloc as neccesary strcpy or memcpy will do as well. Randomly truncating of stings are not really any better than overflowing. (I disagree about this).
They invite the use of fixed buffers of strings, which are unfortunate design in any case where the string length cannot be known beforehand, such as a file name and input
They bloat glibc, if even just by a tiny amount, making every program in linux (near enough) just that much slowly launch. (and yes, glibc is already way too bloated, everyone agrees in this. That does not adding more stuff any better).
As you yourself say, writing the function out and including them around a configure check is pretty much mandatory anyway.
Personally, if I ever wanted to do any development in C that involved more than a few string would be to pick up a better library, that handled the reallocs automatically. If none exists (which I sincerely doubt), I would write it. I prefer C++ for my own writings, or ruby or perl or something, depending on the job at hand.
As for Ulrich Drepper, from my few (electronic) impressions, seems a nice if passionate guy. I'm sure he does the best he can, and I for one appreciate all the efforts he does. He is quite stubborn, which I think is pretty much mandatory in the job he has.
Yes, valgrind helped in Z/Os, not that you can run it there, as I well know, but the bugs that appears in one system tends to be hidden on other systems as well... but for various, the bugs aren't triggered. The most common is branching on uninitialized data, which tend to be completely predicable for a given system. I squashed a great many bugs that way, which helped in the porting. Gdb doesn't run on Z/Os either, at least not in the installation I had. And yes, I've worked on Z/Os, the OS that tended to handle everything a little different. E.g, if you fork()'ed, you had to be sure only to close any sockets in one of the branches, as the FIN... sequence was sent on the first close. Great, eh? Or how about fork() not forking every file handle, automatically closing those it did not want to fork. No, the standards does not, as far as I could determine, prevent an OS from doing this. Add to that the pletora of compiler bugs in IBM's C++ compiler.... I was glad to get out of that.
My point was, most application are easy enough to port, inserting the configure or cmake or whatever checks as neccessary. At least, that is my experience. Of course, if the libraries it uses doesn't work... it can become a big issue. Luckily, I have escaped from that part during my porting works. Porting to windows is a bit harder, but if the GUI toolkit is available on windows (most are), it is not *that* hard, depending on the application of course.
And it's not even just GNU... BSD have their own quirks, like strlcpy, which are so badly thought off that the glibc maintainers (and Linus for that matter) refuses to adopt it into glibc.
However, porting is fairly trivial between unixes. I should know, I've ported stuff to the unix compability layer in Z/OS, which is frankly terrifying implementation of the POSIX and related standards. Tracking down subtle bugs are, of course, not so easy, though valgrind and gdb are a tremendous help.
parent: Everything you haven't experenced first hand, heard about from a reputable source, or believe to be correct from your constrained understanding of the universe is by definition supernatural. It's all supernatural until one day it isn't.
wikipedia: The supernatural (Latin: super- "above" + nature) refers to entities, forces or phenomena which are not subject to normal natural laws, and therefore beyond verifiable measurement.
What parent says is simply not true. According to him, some random Indian guy hugging his beloved is supernatural, yet this is clearly not beyond verifiable measurements, as wikipedia claims to be a requirement. Of course, wikipedia, could be wrong, so let's try dictionary.com:
of, pertaining to, or being above or beyond what is natural; unexplainable by natural law or phenomena; abnormal.
What would you know, it says the same thing.
If being a religious person means believing in something supernatural (like the resurrection of Jesus, women becoming men before going to heaven, thunder from Thor's hammer and so forth) then a religious person is almost certainly wrong about his/her perception of the world. It is hard to quantify how certain, but beyond 99% at least.
The new testament was written long after Jesus death, btw, and the different writers don't agree on much. I remember at least 3 contradictional accounts of the birth of Jesus, e.g. Thus, we can assume that most of these accounts are somewhat or completely wrong.
And don't give me the line about science might be wrong about some details or as-yet unthought experiments. While this is true, this shows the strength of science compared to religion... when science can't match results to theory, it changes the theory... not the other way around. So get back to me when the religious people admit that yes, the mother of Jesus (I forget her name) became a virgin in translation. I mean, we have the original and the translated text, there is really no doubt about this.
On a funnier note, there are rumours that the 72 virgins the martyrs were supposed to enjoy as reward was a mistranslation too. That would be almost too funny. I might die of laughter if this is proven to be true:)
Some people should really learn to either read or shut up. If you'll read the grandgrandparent, you'll notice the discussion was on hardware support out of the box (non-OEM). So I think you owe me an apology.
Anyway, I find linux/Ubuntu much easier to install than boxed winXP32. The reasons for this are
better hardware support out of the box (Yes, that is right, go check the number of supported devices for XPv2 and Linux 2.6.20).
Livecd build in.
Can access the internet, DVD/CDROM drives during install
Superior installation instructions
To reiterate, you are free to disagree with me, but don't call it retarded just because you disagree.
And yes, it doesn't matter too much for windows, since most people buy computers with windows installed and configured already. In this country, that's about $100 out of the window for them, which is of course entirely their own decision:)
For the record, XP service pack 2 doesn't see (out of the box, drivers presumably exists, but as it doesn't install it is a bit hard to test...
SATA disk controller
network card (intel et1000pro)
gfx card but VGA works, so that's ok.
sound card (who cares)
In linux, everything worked right out of the box (and have done so for years)
Interestingly, windows ME worked reasonable out of the box... (but the gfx drivers doesn't). The biggest challenge was selecting the proprietary nvidia drivers.
I know for a fact that the SATA problem is quite common. The solution is to "unpack the CD, slipstream the driver and reburn it on a CD. " No idea how hard it is, I gave up... the few old windows only games are not that important, and everything else, linux does better now.
I also find debugging HW problems much, much easier on linux, which I see is the opposite of your experience. So I suspect that part is about experience more than anything. Though even when I used windows (back at the win95 days) I found that pretty hard... you had to download drivers from vendors websites, which might or might not work. Not quite the point-and-click of linux, but 95 was a long time ago. Maybe windows can manage software in a reasonable way now.
You might be a troll, but in case some impresionnable types were reading it....
I, for one, only buys stuff that support Linux. Life is too short for windows. If it doesn't work on linux, it generally isn't worth owning. oprofile, valgrind, kate, bash, octave, opengl, fork(), GPL'ed kernel, lots of (L)GPL/BSD libraries, KDE (big one), ordered journaling filesystems, liveCDs... the list goes on.
The only advantage windows (for me) had were adventure games. Since games are slowly but surely becoming consoles only, why bother with windows which does less and have a bigger pricetag?
And the argument about pirating windows to avoid pirating movies... that is so sublimely stupid that it deserves the 2007 stupid advice excellency award.
I was speaking of would-be linux-installed computers. You might be right anyway, but give people 10EUR difference in price for no OS vs. no OS... and see what they pick up. I'd hazard people would save the 10 EUR... but as I said, I am not a store businessman at all.
All this has little or no relevance to the heart of the matter... should a store make linux an option and would it cut into his profits if it did?
Why can you add more to the profit line? Your profit is a fixed percentage or something like that?
As to why sell linux...because your computers would be cheaper (-$100?) and thus you'd sell more in comparison to your competition? I'd sell without an OS if possible. People are going to replace the OS anyway, why bother installing one?
But then, I don't know the first thing about running a store and even less about the brick and mortar variety.
In London? Pity it wasn't Copenhagen. Still, being so close to Ireland, there should be some decent Stouts and Porters available. I don't half mind the Fuller's, mindself.
Microbreweries are quite common in Denmark, and some of them makes good beer. It could well be like that in Britain too, but I wouldn't know:) Of course, I belong to the people that believes a good beer is opaque, preferably black.
I wasn't referring to projects, but to languages. You seem to have misunderstood me there. I disagree that Java is a *great* tool for many jobs, although it might be an adequate in many. The greatest advantage of Java is the bandwagon effect... as long as you choose Java, you can dodge responsibility for choosing the wrong language for the job, and also, it is easy to find mediocre programmers that can do some Java.
And sorry about misspelling "achievements". I will try to be more careful, even if it is a second language to me.
Why not just use sea water? Electrolysis of sea water should produce reasonable clean hydrogen, if I recall correctly, and fresh, truly clean water is not very suited without additives.
Not sure about the biological means of producing hydrogen.
Really, crash an app because somebody is using an array rather than an ArrayList? So you're telling me that the programmer not knowing the difference between something with a static (ungrowable) size and a dynamic (growable) size is a fault of the language?
That is the argument you hear all the time. E.g, most buffer overflows in C is due to people using fixed arrays for variable length strings... which makes little sense.
Today, it seems that "archiving goals by lowering expectations" is the norm among application developers... dumping down languages to avoid features that might burn developers.
Happily, there are still quite a slew of languages which are not like that. Too bad that I still have to work in Java sometimes.
Re:This shouldn't be your first Rails review, eith
on
Rails Recipes
·
· Score: 1
I'm not exactly a Ruby guru, but let me try:
models
refers to models in a model-view-controller framework. Every decent application developer should be at least on nodding term with this
migrations
This is the ruby language for describing and versioning databases (both structure and data). Not too different from Java's hibernate, though Ruby makes it somewhat more elegant.
YAML
Yet Another Metalanguage. Think of it as another XML (but not quite as unreadable.) It was never really meant for an XML replacement, but I find Ruby people use it much as Java people do XML.
DSL
I'm a bit blank here. Wild guess would be Domain Specific Language... that is, using a language custom made for a specific purpose. Not a Ruby thing, per-se, but Ruby is sometimes used for this... really, rails is an example.
fixture
It's pertaining to the test framework in Ruby, that's all I know. I've yet to check out this aspect of Ruby
Hope it helps:) It seems every language have some of these. As a C++/Java developer, you would know some of these I suspect: RAII, Bean, session, IFINAE, ByteCode, metaprogramming, serialization, instantiation point. Just to mention a few:)
Any OS that can be modified at all are vulnerable to rootkits provided the attacker gains root priveledges. Microsoft's primary sin was (or is, I havn't kept up) to a) run services that really wasn't hardened for this on wideopen ports b) running those services as root and c) doing so by default.
Had Microsoft not done *all* three, the wormie problem would have been a lot less significant. Had they done none of those three, it might never have happened.
Flamebait? Maybe, but I personally think you are on to something there, though it has little to do with linux per se, but rather with that Ubuntu CD. What about it? It's a livecd. Use that, and you *will* be safe from even the most blatant user errors and the most malicious crackers (but not social engineering, sadly). Replace it once a year to be on the safe side.
Now actually, that would make browsing a mite slow. So maybe an install option where everything is mounted read-only? It might work.
This is of course only meant for the "I write email & browse the web" people. But those are the ones most likely to get hit by something like this.
Slashdot Mirror
I don't normally participate in this sort of debate but.. you have never needed to calculate the volume of anything? And wouldn't that result in a conversion between something like cubic inches and gallons? Just curious.
In my opinion the metric has two advantages, one big, and one somewhat smaller. The big one is that is a standard... a meter is a meter everywhere, while a pint might or might not more than 0.5 liters. The other being that doing rough estimates in your head is much easier if the conversions are easy (to do and remember). The (smallish) disadvantage is the occasional silly big or small unit, like Tesla (big!) and Pa (small!).
Why be so modest? I prefer beer like wine, served in 750ml bottles ;)
You touch upon that strange thing in western society (or perhaps everywhere, I am not sure). Why is seeing sex considered so harmful to children, compared to quite disgusting violence (that can and will give nightmares, etc)? I have a hard time seeing how seeing sex could really harm a human child... especially such a short exposure such as this. I mean, many children must at least have walked in on their parents having sex at some point... and I think most of those children turn out ok anyway. And I'd wager any healthy boy (and girl more likely than not) have seen some kind of porn at 10 year old (and said "ewwww", too).
I just don't see the reasoning there. Anyone know why or how this "sex is harmful to see for children" came about?
Just to point this out: 10+ years ago, our dear scientist created models that predicted a correspondence between CO_2 and the temperature. In the meanwhile, the CO_2 has been steadily increasing, and the temperature likewise. The temperature has been evolving like the models said it would given the evolution in the earths atmosphere --- not just the trend, but the exact temperatures. That is a pretty good test of the theory validity. I has me convinced at least. If I had any money, I'd invest in companies doing ditches and dams :/
You, sir, sound scaringly like me. Must be a mathematician thing. I am far more at home with octave than openoffice, and I'd have a much easier time writing an xml table and style it with xstl+css than do the same in kspread or any other spreadsheet :)
I see I will get nowhere with this. My example string contained abitrary SQL, not a single table name, and anyway, the table names were of an unknown max length (I see I should have used the classed path length, since that one is well known to be of unknowable length.). Also, the spaces were supposed to go in front, I didn't think I needed to spell that out.
strncpy is not meant for general string manipulation, but for putting strings into a record format which is rarely used these days... at least I have not seen it for more than 10 years.
But as you seem to think that anyone not agreeing with you must be an idiot, I am only writing this in case a novice programmer stumbles upon our, eh, conversation and makes that very common mistake about strlcpy. To recap: In the general case, strlcpy is wrong and non-standard, where another function could achieve at least one of those 2. That's 2 good reasons to avoid it.
That it is also a BSD'ism is the fact that got lost somewhere in this thread.
plonk.
A few points, the rest of your post speaks for itself.
As for Linus's opinion, anyone can read it in the linked post. He is against the inclusion in glibc and states that very clearly in that thread, for the reasons I have outlined.
Until the next someone uses some sort of valid filler (like a spaces, or something else) to achieve that chopoff. Boom, security breach. Yeah, I should've checked the return value, but what then would I have done? Raised an error? Reallocated? The code would end up being even uglier. And we all know that requiring developers to check return codes all the time instead of just doing the right thing is a bound to lead to bugs. Which is why C++'s new no longer returns a null pointer if the allocation fails.
The real problem is the usage of a fixed buffers in the first place. str*cpy all encourages using fixed buffers, which is why these people oppose them. We can't get rid of strncpy (without violated the C standard), but we can avoid adding more of these functions, which only gives you a false sense of security. You could read that thread I linked, (not just the random post I linked to yesterday)... it is quite informative.Here it is openSSH's code that is being picked apart.
And I most certainly don't want strncpy. Yeah, I made a typo, forgetting to remove the length while I copied and pasted, so shoot me. I'd get a compile error and remove the extra parameter. The purpose of strncpy and friends is to manipulate records in a database in a certain format; using them for string handling in any other case is insane. You know that, I know that, any C programmer worth his salt knows that, why do you keep bringing strncpy up?
I didn't use strdup since it isn't available on all platforms, and because I wanted to illustrate the general concept (keep track of the length, (re)alloc as necessary. If I was doing this for real, I'd use/write a library, where the stringtype would be something like
Which could be used with library functions to behave correctly in all circumstances. I am sure such an obvious idea is already implemented in some library, though.
PS: Not being rude? What do you call, and I quote,
Wow, talk about full of shit. ? But I commend you latest effort, which is in a nice and sober tone. Thank you for that, I really appreciate it.I have made no nonsense claims, and even if I had, you have no reason to be rude.
For Linus's stand on the issue, please read a post he made on this issue. In fact, skip the rest of this post and just read that thread, Linus is a much better teacher than I ever will be.
Still reading? ok, you don't need to tell me basics about C or it's standard library.. I know the language quite well. And I happen to agree that including strlcpy and friends with glibc is no great harm, as long as a fat warning is included in it's manpage (as well as all the other str* and even mem* should have) about it's shortcomings. However, you blithely ignore the fact that truncating strings based on length likely covers a bug more effectively than the security problem the buffer overflow is. Yes, you might avoid the easy security problem (buffer overflow) but you might introduce a worse one. Consider the example. I can follow Ulrich
Now, given that stack smash protection is pretty much default these days, I'd say the BSD version is the worse security risk, or at least, the one that is hardest to detect. Of course, the design of that program is insane (restricting access in application rather than in the db, e.g.), but I think it illustrates the problem with the strlcpy and friend function pretty clearly.
As for the linuxism... I have had little problem working around them. If you have had trouble with doing that, perhaps I can point out that the source code to each and every non-standard function is available, as well as documentation? Yes, they happen, because like it or not, most people prefer a good function over a portable one, and nothing you or I can do will change this. Nor would I, if I could really. Improving the libraries tend to start at the grassroot level.
Finally, I must declare I am tired of your baseless insults, and will only respond to polite posts from this point on. I can accept shit from great programmers that have illustrated their worthiness, but not from someone who obviously still have a lot to learn.
P.S: Ulrich Drepper's code is incorrect (even if ugly) unlike the code you wrote, at least in the general case. So I think it is taken out of context, as I don't see Drepper making that sort of mistake. The only case strlcpy is valid is if you really want to copy & truncate a string. So if strlcpy was renamed to strcptr(dst,src,n), I think it might be accepted. Though it is a relatively rare usecase, and might be better placed in another library. And once we embarm upon that route, we might as well replace the weak stdlib string library with a safer and better dedicated string library. Like C++ have done with the std::string.
Hey, I don't really have a problem with it, and I resent your language. Learn to talk nice, even if disagree, please. My personal opinion, if you care, is that they are poorly designed functions, but so are just about all the str* function (at least, for inclusion in the stdlib), and 2 more won't really hurt. As I said, it is the glibc team (and yes, Ulrich among them) and Linus that spearheaded rejection of that patch. (I found this out via searching the group with google; I'm sure you can do the same since you seem to care so much)
As I recall, the reasons (not my reasons, though I find them reasonably sounds) were:
Personally, if I ever wanted to do any development in C that involved more than a few string would be to pick up a better library, that handled the reallocs automatically. If none exists (which I sincerely doubt), I would write it. I prefer C++ for my own writings, or ruby or perl or something, depending on the job at hand.
As for Ulrich Drepper, from my few (electronic) impressions, seems a nice if passionate guy. I'm sure he does the best he can, and I for one appreciate all the efforts he does. He is quite stubborn, which I think is pretty much mandatory in the job he has.
Yes, valgrind helped in Z/Os, not that you can run it there, as I well know, but the bugs that appears in one system tends to be hidden on other systems as well... but for various, the bugs aren't triggered. The most common is branching on uninitialized data, which tend to be completely predicable for a given system. I squashed a great many bugs that way, which helped in the porting. Gdb doesn't run on Z/Os either, at least not in the installation I had. And yes, I've worked on Z/Os, the OS that tended to handle everything a little different. E.g, if you fork()'ed, you had to be sure only to close any sockets in one of the branches, as the FIN... sequence was sent on the first close. Great, eh? Or how about fork() not forking every file handle, automatically closing those it did not want to fork. No, the standards does not, as far as I could determine, prevent an OS from doing this. Add to that the pletora of compiler bugs in IBM's C++ compiler.... I was glad to get out of that.
My point was, most application are easy enough to port, inserting the configure or cmake or whatever checks as neccessary. At least, that is my experience. Of course, if the libraries it uses doesn't work... it can become a big issue. Luckily, I have escaped from that part during my porting works. Porting to windows is a bit harder, but if the GUI toolkit is available on windows (most are), it is not *that* hard, depending on the application of course.
And it's not even just GNU... BSD have their own quirks, like strlcpy, which are so badly thought off that the glibc maintainers (and Linus for that matter) refuses to adopt it into glibc.
However, porting is fairly trivial between unixes. I should know, I've ported stuff to the unix compability layer in Z/OS, which is frankly terrifying implementation of the POSIX and related standards. Tracking down subtle bugs are, of course, not so easy, though valgrind and gdb are a tremendous help.
What parent says is simply not true. According to him, some random Indian guy hugging his beloved is supernatural, yet this is clearly not beyond verifiable measurements, as wikipedia claims to be a requirement. Of course, wikipedia, could be wrong, so let's try dictionary.com:
What would you know, it says the same thing.
If being a religious person means believing in something supernatural (like the resurrection of Jesus, women becoming men before going to heaven, thunder from Thor's hammer and so forth) then a religious person is almost certainly wrong about his/her perception of the world. It is hard to quantify how certain, but beyond 99% at least.
The new testament was written long after Jesus death, btw, and the different writers don't agree on much. I remember at least 3 contradictional accounts of the birth of Jesus, e.g. Thus, we can assume that most of these accounts are somewhat or completely wrong.
And don't give me the line about science might be wrong about some details or as-yet unthought experiments. While this is true, this shows the strength of science compared to religion... when science can't match results to theory, it changes the theory... not the other way around. So get back to me when the religious people admit that yes, the mother of Jesus (I forget her name) became a virgin in translation. I mean, we have the original and the translated text, there is really no doubt about this.
On a funnier note, there are rumours that the 72 virgins the martyrs were supposed to enjoy as reward was a mistranslation too. That would be almost too funny. I might die of laughter if this is proven to be true :)
Was that an obscure Red Dwarf reference, or just plain weird?
Apologies for being off topic. Deactivating Karma Bonus
Some people should really learn to either read or shut up. If you'll read the grandgrandparent, you'll notice the discussion was on hardware support out of the box (non-OEM). So I think you owe me an apology.
Anyway, I find linux/Ubuntu much easier to install than boxed winXP32. The reasons for this are
To reiterate, you are free to disagree with me, but don't call it retarded just because you disagree.
And yes, it doesn't matter too much for windows, since most people buy computers with windows installed and configured already. In this country, that's about $100 out of the window for them, which is of course entirely their own decision :)
For the record, XP service pack 2 doesn't see (out of the box, drivers presumably exists, but as it doesn't install it is a bit hard to test...
In linux, everything worked right out of the box (and have done so for years)
Interestingly, windows ME worked reasonable out of the box... (but the gfx drivers doesn't). The biggest challenge was selecting the proprietary nvidia drivers.
I know for a fact that the SATA problem is quite common. The solution is to "unpack the CD, slipstream the driver and reburn it on a CD. " No idea how hard it is, I gave up... the few old windows only games are not that important, and everything else, linux does better now.
I also find debugging HW problems much, much easier on linux, which I see is the opposite of your experience. So I suspect that part is about experience more than anything. Though even when I used windows (back at the win95 days) I found that pretty hard... you had to download drivers from vendors websites, which might or might not work. Not quite the point-and-click of linux, but 95 was a long time ago. Maybe windows can manage software in a reasonable way now.
You might be a troll, but in case some impresionnable types were reading it.... I, for one, only buys stuff that support Linux. Life is too short for windows. If it doesn't work on linux, it generally isn't worth owning. oprofile, valgrind, kate, bash, octave, opengl, fork(), GPL'ed kernel, lots of (L)GPL/BSD libraries, KDE (big one), ordered journaling filesystems, liveCDs... the list goes on. The only advantage windows (for me) had were adventure games. Since games are slowly but surely becoming consoles only, why bother with windows which does less and have a bigger pricetag? And the argument about pirating windows to avoid pirating movies... that is so sublimely stupid that it deserves the 2007 stupid advice excellency award.
I was speaking of would-be linux-installed computers. You might be right anyway, but give people 10EUR difference in price for no OS vs. no OS... and see what they pick up. I'd hazard people would save the 10 EUR... but as I said, I am not a store businessman at all.
All this has little or no relevance to the heart of the matter... should a store make linux an option and would it cut into his profits if it did?
Why can you add more to the profit line? Your profit is a fixed percentage or something like that?
As to why sell linux...because your computers would be cheaper (-$100?) and thus you'd sell more in comparison to your competition? I'd sell without an OS if possible. People are going to replace the OS anyway, why bother installing one?
But then, I don't know the first thing about running a store and even less about the brick and mortar variety.
Have fun :)
In London? Pity it wasn't Copenhagen. Still, being so close to Ireland, there should be some decent Stouts and Porters available. I don't half mind the Fuller's, mindself.
Microbreweries are quite common in Denmark, and some of them makes good beer. It could well be like that in Britain too, but I wouldn't know :) Of course, I belong to the people that believes a good beer is opaque, preferably black.
I wasn't referring to projects, but to languages. You seem to have misunderstood me there. I disagree that Java is a *great* tool for many jobs, although it might be an adequate in many. The greatest advantage of Java is the bandwagon effect... as long as you choose Java, you can dodge responsibility for choosing the wrong language for the job, and also, it is easy to find mediocre programmers that can do some Java.
And sorry about misspelling "achievements". I will try to be more careful, even if it is a second language to me.
Actually, I'd leave it there, but otherwise the salt could be rinsed and sold if feasible.
Why not just use sea water? Electrolysis of sea water should produce reasonable clean hydrogen, if I recall correctly, and fresh, truly clean water is not very suited without additives.
Not sure about the biological means of producing hydrogen.
That is the argument you hear all the time. E.g, most buffer overflows in C is due to people using fixed arrays for variable length strings... which makes little sense.
Today, it seems that "archiving goals by lowering expectations" is the norm among application developers... dumping down languages to avoid features that might burn developers.
Happily, there are still quite a slew of languages which are not like that. Too bad that I still have to work in Java sometimes.
I'm not exactly a Ruby guru, but let me try:
models refers to models in a model-view-controller framework. Every decent application developer should be at least on nodding term with this migrations This is the ruby language for describing and versioning databases (both structure and data). Not too different from Java's hibernate, though Ruby makes it somewhat more elegant. YAML Yet Another Metalanguage. Think of it as another XML (but not quite as unreadable.) It was never really meant for an XML replacement, but I find Ruby people use it much as Java people do XML. DSL I'm a bit blank here. Wild guess would be Domain Specific Language... that is, using a language custom made for a specific purpose. Not a Ruby thing, per-se, but Ruby is sometimes used for this... really, rails is an example. fixture It's pertaining to the test framework in Ruby, that's all I know. I've yet to check out this aspect of RubyHope it helps :) It seems every language have some of these. As a C++/Java developer, you would know some of these I suspect: RAII, Bean, session, IFINAE, ByteCode, metaprogramming, serialization, instantiation point. Just to mention a few :)
Any OS that can be modified at all are vulnerable to rootkits provided the attacker gains root priveledges. Microsoft's primary sin was (or is, I havn't kept up) to a) run services that really wasn't hardened for this on wideopen ports b) running those services as root and c) doing so by default.
Had Microsoft not done *all* three, the wormie problem would have been a lot less significant. Had they done none of those three, it might never have happened.
Flamebait? Maybe, but I personally think you are on to something there, though it has little to do with linux per se, but rather with that Ubuntu CD. What about it? It's a livecd. Use that, and you *will* be safe from even the most blatant user errors and the most malicious crackers (but not social engineering, sadly). Replace it once a year to be on the safe side.
Now actually, that would make browsing a mite slow. So maybe an install option where everything is mounted read-only? It might work.
This is of course only meant for the "I write email & browse the web" people. But those are the ones most likely to get hit by something like this.