Re:Has matz used lisp?
on
Lisp and Ruby
·
· Score: 1
"The authors and users of Dylan would disagree."
Only the ones that pretend Dylan is lisp. Are there alot of them? Just because you have a dynamic functional language, doesn't mean its lisp. Dylan is Dylan.
Even though its trendy to try to attract clueless users by claiming your language has something to do with lisp, the open dylan website doesn't do this. So I question how many of the authors and users pretend its lisp. Dylan was created was to make a language that took what they saw as the good things about lisp (very dynamic, functional), but was completely object oriented and had more limits to the power available (in an attempt to perform better?).
rails is not ruby
on
Lisp and Ruby
·
· Score: 2, Informative
"Download a copy of InstantRails and take 60 minutes to create your own full blown webapplication."
No, make a dinky little toy web app. Even DHH himself doesn't use such blatent exagerations to push rails. Yes its faster than coding everything from scratch, no it is not magic and you can't write anything non-trivial with it in 60 minutes. Do you seriously think anyone anywhere would be using anything but rails if it actually offered a 100x development speed improvement?
"If you think you can do faster and better in Perl, I bow to you mighty Perl God."
Catalyst is for perl what rails is for ruby. There's no need to switch to ruby just to get a web framework.
He asked why to switch to ruby from perl, and you basically ignored ruby altogether and talked about rails. He never even mentioned if he even does web development, how would rails help him if he doesn't do DB driven web development? Ruby itself doesn't offer much over perl, basically just cleaner OO support. If you are already used to perl then I don't think it makes any sense to switch. If you do DB driven web dev and would benefit from rails, then it still makes more sense to stick with perl and just use catalyst (or maypole for trivial 60 minute type stuff) than to switch to ruby just for rails.
Why do you have to stick to scripting?
on
Lisp and Ruby
·
· Score: 1
If you want to do bigger more complex things like writing web servers, why do you want to stick to a scripting language? Regardless, pike is a fast scripting language, and has a C-style syntax. There are webservers written in it (caudium, roxen) that perform well for a scripting language.
It sounds like he's just trying to invent a lisp heritage for ruby to appeal to people who don't know what lisp is, but have heard that its "the most powerful language in the universe!". To quote the link:
* take a simple lisp language (like one prior to CL). * remove macros, s-expression. * add simple object system (much simpler than CLOS). * add blocks, inspired by higher order functions. * add methods found in Smalltalk. * add functionality found in Perl (in OO way).
If you follow steps 1-4, you end up with smalltalk minus the methods that get added in step 5. This whole thing could be reduced to:
* perlify smalltalk
Claiming that ruby is perlified lisp is contrived and silly. Take lisp and remove s-expressions and now you don't have lisp.
Why has register_globals been left in? It should never have made it to php4, nevermind php5. What are the chances it actually gets removed for php6 like they said it would in php5?
Why does zend host tutorials that show how to do things in an insecure way, thus teaching people to write security nightmares?
Why don't the database modules use prepared statements or sprintf() syntax?
It shouldn't require attending conferences and buying magazines to write secure code. I write secure C code without having to do those things! I certainly never had to do anything like that for perl, or python, or pike, or ocaml, or...
I'd argue PHP is actually worse than C, since C at least behaves consistantly and doesn't depend on the settings in some.ini file to get reasonable behaviour. But even if PHP is "no worse than C", that's still incredibly bad for a language designed specifically for web development. C is dangerous because its portable assembly. PHP has no excuse for being dangerous, it was designed specifically for a security sensitive task in an era where exploits had already become common place. The idea of exploiting software was quite foreign in the early 70's when C was born.
"It's easier to trip up badly in C (by commiting some memory buffer error) or Perl (by writing line noise code that you can't understand a week later) than PHP. But it's no longer fashionable to bash those languages."
First of all, its still VERY fasionable to bash C for being dangerous. There's a big difference though, C is not designed especially for web development. It was designed (decades ago!) as portable assembly. Assembly is dangerous, so portable assembly is too. PHP is a high level language designed for a task that requires alot of attention to security. It fails miserably to be suitable for this task. C succeeds very well at being portable assembly.
Second, as much as I dislike alot of perl's shortcuts, they don't tend to lead to security problems. Its definately easier to write secure perl than to write secure PHP. And perl and C both behave how you want when you are writing code in them. PHP behaves differently depending on how someone has messed with the php.ini. Have fun testing with all the variations of possible php.ini settings.
Zend posts PHP tutorials and examples on their site that show how to write code with huge gaping security holes, and say "its ok because people shouldn't just copy our examples" when you point it out. When the developers of the language are giving newbies examples that are full of security holes, and don't even think that's bad, you know there's no hope.
I do have the ability to write secure PHP code. And it takes much longer and much more effort than when I write secure perl, or python, or pike code. Because the language is poorly designed and has tons of misfeatures that promote security holes. Just because you *can* write secure PHP with enough time and effort, doesn't mean PHP is secure. The language should not go out of its way to make writing secure code more difficult.
"Your implication is you do NOT need a great deal of effort to port it to a particular Linux distro. Yet the effort Debian or Slackware spend packaging KDE is just as great as the effort spent by FreeBSD."
Because you don't. They choose to patch it to make it behave the way they want for their distro. That's fine, but its not required. It does require patches for it to function correctly on BSDs. Yes, KDE is very good at releasing test candidates and taking patches from the BSD people so that by the time the release comes out it works out of the box, I am not saying KDE sucks or KDE developers suck. I am just saying KDE developers do in fact target linux, and other people fix it for other OSs.
"Care to give an example of the alledged inferiority/superiority?"
Look at all the gnu utils. They are bloated to twice the size or more of what they should be, full of duplicated, superfluous, non-standard options that make them slower and reduce portablility. Hell, they managed to fuck up tar for crying out loud, using a non-standard gnu extension that causes more problems than it solves. gsed, gawk, bash, fileutils, info especially. Its all bloated crap.
"I do not think my questions are weird. Well, maybe they are, for those who cannot think consistently:"
They are definately weird, because you are not thinking consistantly. I simply stated that each BSD already includes are userland, so the original poster has no need to wait for a debian or gentoo userland. You responded with bizzare questions about totalitarianism and kernel developers stopping you from running software, neither of which are relevant or make any sense.
"Repeat after me: kernel is one thing, "userland" (I hate the term) is another, they have nothing to do with each other, and so it is perfectly fine to use a BSD (or any other) kernel in gentoo or debian"
What are you smoking? There is nothing wrong with the term userland, kernels and userlands do have something to do with each other when they are developed together and/or specifically for each other (e2fsprogs kinda goes with the linux kernel don't you think?). It is perfectly fine to use a BSD kernel in gentoo or debian, but its also completely stupid and there's no need for it. If someone wants to not use linux, they can just use a BSD or solaris right now, they already have their own userlands, you don't need to wait for someone to get a debian or gentoo userland running on a BSD or solaris kernel.
"and then went back to Slackware, feeling good again exactly because there was virtually no package or configuration management, and my userland consisted primarily of the "random crap" -- programs compiled from sources I downloaded directly from their authors' websites."
You really are a dumbass aren't you? Slackware has package management, and it forces a default userland on you. If you choose to install random stuff from source for no reason, that's up to you. But you can do that just as well on any other linux distro, or a BSD, or solaris. Having package managment doesn't force you to use it obviously, since slackware has package management.
"One thing that has been making me sick was exactly that supid old song of BSD fanboys about BSD's "superiority" and that it is not a kernel but an OS. So what? Debian is not a kernel either, and, again, why should I care? Why don't y'all change the tune, or, better yet, just shut up."
If it makes you sick, then why are you so obsessed with it, and why are you pretending it has anything to do with me? I didn't say any given BSD is better than any thing else because its an OS. Debian and gentoo are also OSs, that doesn't even make sense. You really should quit making up stuff that makes you sick.
"As for software that was written for BSDs or Solaris that has trouble running on Linux, that's the whole point I suppose. While there may be less of these packages, there tend to be enough volunteers who will work with the software's developers to ensure that it does work under Linux"
Its not volunteers though, its the developers. I develop on openbsd since its a much better platform for C development than other unixes. I fix it for linux, solaris and hp-ux (and test on freebsd and netbsd, but only occasionally have to fix a freebsd problem, it usually is fine). I know people who develop on Solaris, and they test on linux and freebsd too. They don't just release their code as-is and wait for users to submit patches to get it working on linux and BSDs, they take the time to do it themselves. This is the difference, developers are writing for linux, and making other people fix it. This doesn't happen the other direction (ignoring of course OS included utils, I don't expect Sun to make sure their userland software runs on linux and BSD).
"In the end, most software I build runs on the UNIX, FreeBSD and Linux/GNU UNIX-like systems we support."
Because someone ported it. It was developed for linux, then 3rd parties fixed it for other OSs. This isn't a difficult concept. Most of the software I build runs on most unixes too, including netbsd and openbsd, and dragonflybsd. But I am also more careful and look through config.log's and see the little oopses and fix those, instead of blindly ignoring them because "it compiled so its ok". As someone who has submitted the patches that make software "just work" on various OSs, I find it insulting that you assume everything has just always worked and nobody has been involved in making that the case.
"For that reason, I'll call it UNIX software"
You can call it whatever you want, but that doesn't change the fact that it is, contrary to the original posts assertion, targetted at linux.
"I'm happy to say that I don't need to support the OpenBSD platform in our environment, nor NetBSD for that matter, and won't support its inclusion in the future given the trouble you seem to be having."
The only trouble I am having it getting you to grasp the simple concept of "yes, developers do target linux specifically". I am not sure how that is either openbsd's nor netbsd's fault, but I do hope you will try to avoid them. I know its a little schadenfreude, but I do take pleasure in knowing dumbasses go out of their way to make their lives worse to spite other people. I always get a laugh at the linux users who whine about how BSD X is not exactly like linux, "so I'm going to go back to linux and not using BSD, take that!". Like it somehow hurts me that you are avoiding better operating systems. Ow, my pancreas!
My head asplode! Are you trolling or just really high?
"what if I do not want kernel developers to dictate me what userland software to use ("totalitarianism"),"
How are they supposed to do that? Its your computer, you decide what software to use. No developers (kernel or otherwise) have anything to do with it. Debian provides a userland for you. Gentoo provides a userland for you. FreeBSD provides a userland for you. OpenBSD provides a userland for you. In all of these cases if you don't like any particular piece, you are free to install and use something else. Is debian "totalitarianism" because they give me bash by default? No, I just install ksh and now I have a usable shell. Why would you think it would be any different in any other OS? How are the kernel programmers going to stop you from installing whatever software you want, why would they care to, and why do you think they somehow magically do?
"what if I want to be able to choose from a myriad of Unix programs that are out there (the ones that you call "random crap")."
Then you install them and use them, duh? And I didn't call the myriad of unix programs that are out there "random crap". I called the random crap that fills in the holes in the otherwise totally GNU userland "random crap". Stuff like file, less, ncurses, etc. It wasn't to say that any particular piece of software in that list is crappy, just that its together "random crap". A bunch of unrelated programs all tossed together from different sources.
"Is it really true, by the way, that BSD users never use "the awful" GNU software?"
No, each individual BSD users uses whatever the hell they want, just like each individual user of any other OS. Why do you keep asking weird questions that have nothing to do with anything? Are you trying to win some kind of bizzare non sequitur award? I said nothing about what software BSD users use, I said each BSD already has a userland, so there's no need to wait for debian or gentoo to get their inferior userlands ported to a BSD kernel. BSDs aren't just kernels, they are OSs, they come with userlands already.
"Well, we're supposedly discussing the desktop. I'll pick a few from mine. How about KDE? A large number of KDE apps originated on Linux. XMMS definitely originated on Linux, and it works on OpenBSD. The mplayer program works on OpenBSD as well. It took a few minutes to come up with and verify that list. The list grows much larger when you include FreeBSD, since more people seem to use it."
Huh, why are you listing software developed on and for linux? I asked for examples of people writing code for solaris or BSD that linux users have to fix to get working, since you claim that happens too.
"Scarcely, FreeBSD has everything that WINE needs to run."
So do openbsd and netbsd. It was alot of work to get wine running on freebsd, dismissing the work those people did won't make it dissapear.
"When OpenBSD supports everything that WINE currently needs, it won't be as difficult so much as potentially time consuming given the size of the code"
It already does support everything wine needs. Its still as difficult to port right now as it was yesterday.
"A cursory look into the issue shows that kernel level thread support is currently holding back the OpenBSD port, which isn't a WINE issue as much as an issue for OpenBSD threads."
A cursory look into the website you mean. OpenBSD has kernel threads. Rather than reading an incorrect note someone who didn't try porting wrote, try compiling the code. You will see it has nothing to do with kernel threads at all. Hell, I've had wine developers tell me that OpenBSD is fully supported and the latest wine works on it fine. They don't seem to pay much attention to what works and why.
"WINE can be run on other BSD systems until then."
No, just freebsd and the freebsd compatible systems (PC BSD and such). It doesn't run on netbsd either.
"It's software that now has a FreeBSD port."
Has a freebsd port because of freebsd users. It was and is developed on and for linux, and requires 3rd parties to fix it. If the developer of the software made sure it ran on freebsd, then it wouldn't be linux software. But if the developer just develops it on and for linux, and then 3rd parties have to fix it for other OSs, then its clearly targetting linux, like I said, and contrary to the original posters blately incorrect statement.
"Your insistence in calling it Linux software is where we disagree and will continue to do so. Unless it accesses a kernel specific resource, there's nothing Linux particular about it. There may be GNUisms, or code that leans toward SysV, but that's a different issue."
Linux isn't just a kernel, its also an OS. Wether you like the fact that linux is a name for 2 things or not won't change that. Even all the indignation that RMS can muster has not and will not change this. Using glibc functionality is targetting linux (the OSs), as that is what linux (the OSs) includes with linux (the kernel).
I don't draw that line, the people creating OSs draw those lines for their OSs. What on earth does this have to do with anything? I just asked a simple question. BSDs already have userlands, they come with shells and all the usual assortment of command line utilities, and package management to add more stuff. What is the point of using the awful GNU/random userland that debian and gentoo subject you to on top of a BSD kernel? There's no need to wait for a debian or gentoo userland to be working nicely on a BSD kernel since each of the BSD kernels comes with a better userland anyways. If you have an answer to that question feel free to speak up, but asking me random questions that have nothing to do with anything isn't clarifying things at all.
"For Free and Open Source software, sure it does."
Name some examples then. There's tons of open source code that is targetted directly at linux. There is very little targetted at any other unix. I know several people who develop exclusively on solaris or their BSD of choice, and all of them have linux and either solaris or a BSD (whichever they aren't using obviously) installed in a VM of some sort for testing. I don't know of anyone who develops primarily on linux and does the same. They all just assume real unixes are scary and hard to use and so rely on other people to fix their code for them.
"It works on FreeBSD, which is a BSD and not Linux. Tell me then, why is it so difficult to get it running on OpenBSD?"
Because FreeBSD people took the time to fix it for FreeBSD. And they keep taking that time over and over and over again since the wine developers keep writing more linux only code.
"Is WINE FreeBSD software as well?"
No, its linux software that dedicated FreeBSD fans have ported.
"probably not even as difficult as you think."
Probably exactly as difficult as I think, I tried. Now you go try instead of pretending its so easy. You are insulting all the people who spent the time getting it working on FreeBSD with your ignorance.
"I'm not pretending; I'm telling you you're complaining about fringe platforms being ignored that do not in themselves define UNIX"
Yes, you are pretending. I have made it very clear over and over and over again what I am saying, and you are ignoring that, pretending I am saying something else, and arguing against that. You don't need me for that, go argue with your made up pretend me on your own. You can grab an old sock and make a me puppet to argue with if you can't respond to what I say instead of what you want me to say. Just make sure you give the me sock puppet a nice moustache.
"If you're saying that there are a lot of GNU applications that never get ported to your favorite platform"
I didn't say they never get ported, I said THEY NEED PORTING. Much of it is ported, some is not. Either way its totally irrelivant, the point is that it needed ported to begin with because the authors wrote it for linux + gcc + glibc. What the hell kind of mental block is crippling your ability to grasp this simple concept?
"Most programmers I know go with the current ANSI C standard as supported by their compiler and OS libraries."
No, they ignore the C standard and go with gcc + glibc.
"You're complaining that a lot of software is written on Linux and somehow never gets ported to other platforms."
This is the last time I will say this, obviously you are choosing not to listen because you like strawman arguments. I am making this as clear as I possibly can, please read this instead of making up more bullshit and pretending I said it:
PEOPLE WRITE SOFTWARE FOR LINUX.
Are we clear? That is what I am saying. That is all I am saying. I am not complaining about anything except your refusal to stick to what I am saying instead of what you want me to be saying. The original poster claimed that people do not write software for linux, but again, and as you are clearly aware of since you've admitted it over and over:
PEOPLE WRITE SOFTWARE FOR LINUX.
It is a correction of the incorrect post. Nothing more. Stop reading anything else into it, everything else is in your imagination. Its unfortunate that in trying to demonstrate to you that PEOPLE WRITE SOFTWARE FOR LINUX, you focus in on all sorts of details in the examples and ignore the point, that PEOPLE WRITE SOFTWARE FOR LINUX.
"Also, the spaces were supposed to go in front, I didn't think I needed to spell that out."
And that still does not lead to a security hole. You can't even make up an example where you shouldn't use strlcpy? You're entire argument is that because strlcpy is not meant to be used for everything it should not be used at all. memcpy is not meant to be used for everything either, yet there it is. Just because you can use a function wrong, does not mean it adds no value since you can also use it right.
"strncpy is not meant for general string manipulation"
Yes it is, it was meant as a bounded strcpy. It does this task very poorly, hence strlcpy replacing it. Why do you think its named strncpy? It has nothing to do with your bizzare record format nonsense, its strcpy with a length.
And you can see strncpy in use all over the place, grep the source tree of most open source C programs and you will see strncpy being used.
"But as you seem to think that anyone not agreeing with you must be an idiot,"
No, I made it quite clear that failing to understand someone else's opinion, presenting it as your own in an incorrect and obviously stupid example, while pretending to be an authority on secure C programming makes you an idiot. Ulrich Drepper thinks strlcpy is bad too, but he at least knows C and is capable of making up examples where you shouldn't use strlcpy. Hence he's not an idiot, just a liar for pretending that's why he won't include it when its really his NIH complex where he wants to push his non-standard mempcpy function over someone else's non-standard strlcpy function. Obviously he has no problem with the concept of such a function, or including non-standard functions or else mempcpy wouldn't be in glibc. He just wants people to use his non-standard extension over the one that looks nicer and is already widely adopted.
"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."
To recap: strncpy fails to guarentee NULL termination and doesn't let you check truncation. strlcpy solves these problems and is faster than strncpy. Use strlcpy instead of strncpy, its 51 lines long including the license, you can use it in any project. Nobody with any background in secure C programming denies the usefulness of strlcpy/cat. The only people who argue against strlcpy/cat are people with an agenda of pushing their strncpy alternatives, or people like you who just regurgitate those people's rhetoric without understanding it. Even systems without strlcpy like plan 9 include some function to replace strncpy securely, showing that wether or not you want the particular implimentation that is strlcpy, there is a need and desire to have a secure strncpy replacement.
"That it is also a BSD'ism is the fact that got lost somewhere in this thread."
First of all, its not a BSDism. All the BSDs are smart enough to include it in their libc, yes. But so do Solaris and Windows services for unix. Just because a couple programmers from one of the BSDs made the functions initially, doesn't make it a BSDism. It would be a BSDism if it only was found in BSDs.
Second, the fact that people who use it include it in their code got lost on you. Its not relying on a BSDism if you include the function in your code, use your head. That's like saying that using daemon() is a relying on a BSDism, when in fact most unix systems have daemon(), and you can can include it for those that don't. Or that using sockets is relying on a BSDism. A ton of current unix implimentations came from a BSD initially, its only a problem if you blindly assume every system is the same.
I never said people shouldn't use non-standard extentions like gnuisms, just that they should not RELY on them. So if you include the functions in question, you are all good. Pretty simple huh?
"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."
Anyone can grep -r strlcpy in the kernel source tree too. Actions speak louder than flamewars, especially considering Linus' tendancy to flame people because they are smarter than him, then quietly do what they said in the background because he knows they are right.
"Until the next someone uses some sort of valid filler (like a spaces, or something else) to achieve that chopoff. Boom, security breach."
Boom, wtf are you talking about? If the max table length is 255 lets say, and someone puts a 255 char table name in plus a bunch of spaces which we truncate, how is that any different from them just putting in the 255 char table name to begin with? This has nothing to do with anything, why do you think its a security breach?
"Yeah, I should've checked the return value, but what then would I have done? Raised an error?"
Gee, what do you think you should do when you get a table name longer than the max length of a table name? Sounds like an error to me.
"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."
We all don't know that. If you don't like C then don't use it. But refusing to include useful C functions because you don't like that they behave consistantly with the rest of C is moronic at best.
"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."
And fixed buffers make perfect sense, because a tons of things have a fixed max size, like table names. Your example is a perfect example of why strlcpy IS GOOD. You would need to recreate strlcpy's behaviour to make your example correct and secure.
"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."
Yes, it is quite informative. It shows both how ignorant Linus is, and how he likes to flame people for being better programmers than him, while in the background copying the same thing he is flaming them for. That's not openssh's code being picked apart, its a typo'd version of a few lines being bitched about by idiots who haven't actually looked at the code. Considering the security track records of linux and openbsd, Linus has no place to be telling openbsd developers about secure coding. I will trust history over a bizzare fetish where you have convinced yourself that Linus knows anything about secure programming.
"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?"
BECAUSE strlcpy IS A REPLACEMENT FOR strncpy! Are you retarded? I bring it up because its 100% relevant, it is in fact the whole fucking point. strlcpy is a correct, secure and effecient replacement for strncpy, so obviously it is to be used instead of strncpy. In situations where you are dealing with fixed size buffers. And despite ignorant, memory exhaustion error filled code that tries to show otherwise, this is very often the case. I was right to insult you in the first post, I apologize for not being more of a dick in the second post. You are a fucking idiot.
"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."
And so you gave an example where it makes no sense at all to realloc, and where it would slow down the code and create security holes if you did? TABLE NAMES HAVE A MAX LENGTH. THEY ARE FIXED SIZE. Why do you think using a function that operatings of fixed length strings whe
"Most definitely not. The vast majority of code out there gets developed for one OS (particularly Win32 and embedded operating systems, but it happens enough in the *NIX world too) and runs there"
We're talking about open source projects remember? Seriously, every project I know developed primarily on a non-linux unix is tested and fixed for linux at least, and usually BSD and solaris as well. This doesn't occur very often going the other way.
"Not to be rude, but really, why would most people care?"
Not to be rude, but are you incapable of grasping simple concepts? I DO NOT CARE. You said its trivial to port software, I pointed out an example of how non-trivial it can be. Why do you persist in pretending I give a shit about porting any given piece of software? I have made it very clear several times now that I am simply correcting the false assertion that people don't develop for linux. They do.
"GLIBC is part of the GNU system and uses GNU conventions. That's about as close to a standard as one can get in the current fragmented UNIX environment"
No, there is the C standard actually.
"In all likelihood, it's because noone cares enough to do anything about it. Do you?"
No, I do not. Try to read what you are replying to.
"I'm not saying there aren't any linuxims in KDE, because there are."
Right, that's the point. It is written for linux, and then users of other systems have to fix it for their systems. So its not a case of linux distros using KDE and Gnome as kotj.mf thinks. Quite the opposite, it is a case of Gnome and KDE developers using linux.
Yes really. People develop for linux. He said people don't develop for linux. But that's exactly what they do. Its very simple.
"By your logic, if people wrote software for Solaris then they were writing code not for UNIX but for Solaris only; In order to compile for SunOS 4.x, HPUX, AIX, IRIX, Tru64, Free/Net/OpenBSD, and other UNIX systems there would need to be changes made because each system is a bit different."
Right, they would be devloping for solaris. But people don't do that. People who develop primarily on Solaris or a BSD of their choice are almost always nice enough to test their software on other free OSs and make sure it works. I can understand people not making sure their stuff works on AIX or HP-UX or whatever, but solaris and BSDs and linux and darwin are all free. There's really no reason not to make your software work on them besides laziness.
"but I've built software for many systems that weren't necessarily the original coder's targets and it's not that difficult."
That depends on the software. Trivial software tends to be trivial to port. Go get wine working on openbsd and tell me how easy that is.
"You're simply trying to pin Linux and GNU systems down as the only odd ones out there, whereas most systems have a variety of small differences."
No, it has nothing to do with linux being the odd one out, its just popular. And I am not pinning anything, I am simply correcting a completely wrong statement. It would be just as dumb to develop software for netbsd/arm only and not bother testing it out on other platforms. But that's not what people do.
"The most differences for that matter are probably between the BSDs and SysV based systems. Take a look at the output of autoconf's "configure" on multiple UNIX flavors and you'll see what I mean; even SysV systems can have different numbers of arguments for various library functions."
No need, I actually write unix software in C. I know there's alot of differences. And I test out my code on a wide variety of hardware and software platforms before making releases so that I don't let BSDisms creep into my software. I am not sure why you keep trying to convince me of things I am already aware of, what does any of this have to do with the original post? Yes, people do develop directly on and for linux, with no regard to other OSs. That is exactly what happens in many cases. Hence the original post claiming people develop for posix plus nonexistant "standards" is wrong. The part about people coding for glibc is correct however, he just seems to mistakenly think glibc is a standard.
"Nonsense! Get out from behind that rock and see the real world!"
I'm sure the people who spend hours making it so you can run KDE on freebsd really appreciate your gratitude. I am not trying to trash KDE, I don't even use it. I am just saying that yes, it is in fact developed by linux users, for linux users, on linux machines. Then BSD people fix it. KDE people are nice enough to take the patches, but they still developed linux software, and BSD people fixed it. This nonsense claim that people are developing cross platform code that works out of the box everywhere is crazy.
"Go look at those patches you talk about. They are either standard bug/exploit fixes, changes to hardcoded file paths and names, or they're changes to default values."
I did look, plenty of them are fixing linuxisms. Even little things like ifdefs being in the wrong places so that the code doesn't compile if LINUX_ONLY_FEATURE_X is not defined.
There is no invalidating his point, he is simply wrong. What he said is incorrect.
"It is very unlikely that developers follow Linux only."
Yes, that is exactly what most of them do. They use linux, and develop on and for linux.
"They support some well documented and mature standards like Gnu Libc, X window and POSIX, among others."
Glibc is not a standard, and the fact that people do program for it is "following linux only".
"Infact, for example, most of the desktop software can be compiled and run under almost all OS that comply to those standards."
In fact, most of it cannot. It has to be altered to work on all the other OSs. Because it is written for linux.
See, he is wrong, and clearly you know that since you've pointed out reasons why people write linux code. How easy or hard it is to fix that code is both irrelivant, and varies tremendously depending on the code.
Slashdot Mirror
"The authors and users of Dylan would disagree."
Only the ones that pretend Dylan is lisp. Are there alot of them? Just because you have a dynamic functional language, doesn't mean its lisp. Dylan is Dylan.
Even though its trendy to try to attract clueless users by claiming your language has something to do with lisp, the open dylan website doesn't do this. So I question how many of the authors and users pretend its lisp. Dylan was created was to make a language that took what they saw as the good things about lisp (very dynamic, functional), but was completely object oriented and had more limits to the power available (in an attempt to perform better?).
"Download a copy of InstantRails and take 60 minutes to create your own full blown webapplication."
No, make a dinky little toy web app. Even DHH himself doesn't use such blatent exagerations to push rails. Yes its faster than coding everything from scratch, no it is not magic and you can't write anything non-trivial with it in 60 minutes. Do you seriously think anyone anywhere would be using anything but rails if it actually offered a 100x development speed improvement?
"If you think you can do faster and better in Perl, I bow to you mighty Perl God."
Catalyst is for perl what rails is for ruby. There's no need to switch to ruby just to get a web framework.
He asked why to switch to ruby from perl, and you basically ignored ruby altogether and talked about rails. He never even mentioned if he even does web development, how would rails help him if he doesn't do DB driven web development? Ruby itself doesn't offer much over perl, basically just cleaner OO support. If you are already used to perl then I don't think it makes any sense to switch. If you do DB driven web dev and would benefit from rails, then it still makes more sense to stick with perl and just use catalyst (or maypole for trivial 60 minute type stuff) than to switch to ruby just for rails.
If you want to do bigger more complex things like writing web servers, why do you want to stick to a scripting language? Regardless, pike is a fast scripting language, and has a C-style syntax. There are webservers written in it (caudium, roxen) that perform well for a scripting language.
It sounds like he's just trying to invent a lisp heritage for ruby to appeal to people who don't know what lisp is, but have heard that its "the most powerful language in the universe!". To quote the link:
* take a simple lisp language (like one prior to CL).
* remove macros, s-expression.
* add simple object system (much simpler than CLOS).
* add blocks, inspired by higher order functions.
* add methods found in Smalltalk.
* add functionality found in Perl (in OO way).
If you follow steps 1-4, you end up with smalltalk minus the methods that get added in step 5. This whole thing could be reduced to:
* perlify smalltalk
Claiming that ruby is perlified lisp is contrived and silly. Take lisp and remove s-expressions and now you don't have lisp.
Why has register_globals been left in? It should never have made it to php4, nevermind php5. What are the chances it actually gets removed for php6 like they said it would in php5?
Why does zend host tutorials that show how to do things in an insecure way, thus teaching people to write security nightmares?
Why don't the database modules use prepared statements or sprintf() syntax?
It shouldn't require attending conferences and buying magazines to write secure code. I write secure C code without having to do those things! I certainly never had to do anything like that for perl, or python, or pike, or ocaml, or...
I'd argue PHP is actually worse than C, since C at least behaves consistantly and doesn't depend on the settings in some .ini file to get reasonable behaviour. But even if PHP is "no worse than C", that's still incredibly bad for a language designed specifically for web development. C is dangerous because its portable assembly. PHP has no excuse for being dangerous, it was designed specifically for a security sensitive task in an era where exploits had already become common place. The idea of exploiting software was quite foreign in the early 70's when C was born.
"It's easier to trip up badly in C (by commiting some memory buffer error) or Perl (by writing line noise code that you can't understand a week later) than PHP. But it's no longer fashionable to bash those languages."
First of all, its still VERY fasionable to bash C for being dangerous. There's a big difference though, C is not designed especially for web development. It was designed (decades ago!) as portable assembly. Assembly is dangerous, so portable assembly is too. PHP is a high level language designed for a task that requires alot of attention to security. It fails miserably to be suitable for this task. C succeeds very well at being portable assembly.
Second, as much as I dislike alot of perl's shortcuts, they don't tend to lead to security problems. Its definately easier to write secure perl than to write secure PHP. And perl and C both behave how you want when you are writing code in them. PHP behaves differently depending on how someone has messed with the php.ini. Have fun testing with all the variations of possible php.ini settings.
Zend posts PHP tutorials and examples on their site that show how to write code with huge gaping security holes, and say "its ok because people shouldn't just copy our examples" when you point it out. When the developers of the language are giving newbies examples that are full of security holes, and don't even think that's bad, you know there's no hope.
I do have the ability to write secure PHP code. And it takes much longer and much more effort than when I write secure perl, or python, or pike code. Because the language is poorly designed and has tons of misfeatures that promote security holes. Just because you *can* write secure PHP with enough time and effort, doesn't mean PHP is secure. The language should not go out of its way to make writing secure code more difficult.
"Your implication is you do NOT need a great deal of effort to port it to a particular Linux distro. Yet the effort Debian or Slackware spend packaging KDE is just as great as the effort spent by FreeBSD."
Because you don't. They choose to patch it to make it behave the way they want for their distro. That's fine, but its not required. It does require patches for it to function correctly on BSDs. Yes, KDE is very good at releasing test candidates and taking patches from the BSD people so that by the time the release comes out it works out of the box, I am not saying KDE sucks or KDE developers suck. I am just saying KDE developers do in fact target linux, and other people fix it for other OSs.
"Care to give an example of the alledged inferiority/superiority?"
Look at all the gnu utils. They are bloated to twice the size or more of what they should be, full of duplicated, superfluous, non-standard options that make them slower and reduce portablility. Hell, they managed to fuck up tar for crying out loud, using a non-standard gnu extension that causes more problems than it solves. gsed, gawk, bash, fileutils, info especially. Its all bloated crap.
"I do not think my questions are weird. Well, maybe they are, for those who cannot think consistently:"
They are definately weird, because you are not thinking consistantly. I simply stated that each BSD already includes are userland, so the original poster has no need to wait for a debian or gentoo userland. You responded with bizzare questions about totalitarianism and kernel developers stopping you from running software, neither of which are relevant or make any sense.
"Repeat after me: kernel is one thing, "userland" (I hate the term) is another, they have nothing to do with each other, and so it is perfectly fine to use a BSD (or any other) kernel in gentoo or debian"
What are you smoking? There is nothing wrong with the term userland, kernels and userlands do have something to do with each other when they are developed together and/or specifically for each other (e2fsprogs kinda goes with the linux kernel don't you think?). It is perfectly fine to use a BSD kernel in gentoo or debian, but its also completely stupid and there's no need for it. If someone wants to not use linux, they can just use a BSD or solaris right now, they already have their own userlands, you don't need to wait for someone to get a debian or gentoo userland running on a BSD or solaris kernel.
"and then went back to Slackware, feeling good again exactly because there was virtually no package or configuration management, and my userland consisted primarily of the "random crap" -- programs compiled from sources I downloaded directly from their authors' websites."
You really are a dumbass aren't you? Slackware has package management, and it forces a default userland on you. If you choose to install random stuff from source for no reason, that's up to you. But you can do that just as well on any other linux distro, or a BSD, or solaris. Having package managment doesn't force you to use it obviously, since slackware has package management.
"One thing that has been making me sick was exactly that supid old song of BSD fanboys about BSD's "superiority" and that it is not a kernel but an OS. So what? Debian is not a kernel either, and, again, why should I care? Why don't y'all change the tune, or, better yet, just shut up."
If it makes you sick, then why are you so obsessed with it, and why are you pretending it has anything to do with me? I didn't say any given BSD is better than any thing else because its an OS. Debian and gentoo are also OSs, that doesn't even make sense. You really should quit making up stuff that makes you sick.
"As for software that was written for BSDs or Solaris that has trouble running on Linux, that's the whole point I suppose. While there may be less of these packages, there tend to be enough volunteers who will work with the software's developers to ensure that it does work under Linux"
Its not volunteers though, its the developers. I develop on openbsd since its a much better platform for C development than other unixes. I fix it for linux, solaris and hp-ux (and test on freebsd and netbsd, but only occasionally have to fix a freebsd problem, it usually is fine). I know people who develop on Solaris, and they test on linux and freebsd too. They don't just release their code as-is and wait for users to submit patches to get it working on linux and BSDs, they take the time to do it themselves. This is the difference, developers are writing for linux, and making other people fix it. This doesn't happen the other direction (ignoring of course OS included utils, I don't expect Sun to make sure their userland software runs on linux and BSD).
"In the end, most software I build runs on the UNIX, FreeBSD and Linux/GNU UNIX-like systems we support."
Because someone ported it. It was developed for linux, then 3rd parties fixed it for other OSs. This isn't a difficult concept. Most of the software I build runs on most unixes too, including netbsd and openbsd, and dragonflybsd. But I am also more careful and look through config.log's and see the little oopses and fix those, instead of blindly ignoring them because "it compiled so its ok". As someone who has submitted the patches that make software "just work" on various OSs, I find it insulting that you assume everything has just always worked and nobody has been involved in making that the case.
"For that reason, I'll call it UNIX software"
You can call it whatever you want, but that doesn't change the fact that it is, contrary to the original posts assertion, targetted at linux.
"I'm happy to say that I don't need to support the OpenBSD platform in our environment, nor NetBSD for that matter, and won't support its inclusion in the future given the trouble you seem to be having."
The only trouble I am having it getting you to grasp the simple concept of "yes, developers do target linux specifically". I am not sure how that is either openbsd's nor netbsd's fault, but I do hope you will try to avoid them. I know its a little schadenfreude, but I do take pleasure in knowing dumbasses go out of their way to make their lives worse to spite other people. I always get a laugh at the linux users who whine about how BSD X is not exactly like linux, "so I'm going to go back to linux and not using BSD, take that!". Like it somehow hurts me that you are avoiding better operating systems. Ow, my pancreas!
My head asplode! Are you trolling or just really high?
"what if I do not want kernel developers to dictate me what userland software to use ("totalitarianism"),"
How are they supposed to do that? Its your computer, you decide what software to use. No developers (kernel or otherwise) have anything to do with it. Debian provides a userland for you. Gentoo provides a userland for you. FreeBSD provides a userland for you. OpenBSD provides a userland for you. In all of these cases if you don't like any particular piece, you are free to install and use something else. Is debian "totalitarianism" because they give me bash by default? No, I just install ksh and now I have a usable shell. Why would you think it would be any different in any other OS? How are the kernel programmers going to stop you from installing whatever software you want, why would they care to, and why do you think they somehow magically do?
"what if I want to be able to choose from a myriad of Unix programs that are out there (the ones that you call "random crap")."
Then you install them and use them, duh? And I didn't call the myriad of unix programs that are out there "random crap". I called the random crap that fills in the holes in the otherwise totally GNU userland "random crap". Stuff like file, less, ncurses, etc. It wasn't to say that any particular piece of software in that list is crappy, just that its together "random crap". A bunch of unrelated programs all tossed together from different sources.
"Is it really true, by the way, that BSD users never use "the awful" GNU software?"
No, each individual BSD users uses whatever the hell they want, just like each individual user of any other OS. Why do you keep asking weird questions that have nothing to do with anything? Are you trying to win some kind of bizzare non sequitur award? I said nothing about what software BSD users use, I said each BSD already has a userland, so there's no need to wait for debian or gentoo to get their inferior userlands ported to a BSD kernel. BSDs aren't just kernels, they are OSs, they come with userlands already.
Do you like peanut butter and ketchup sandwiches?
Did not think so...
"Well, we're supposedly discussing the desktop. I'll pick a few from mine. How about KDE? A large number of KDE apps originated on Linux. XMMS definitely originated on Linux, and it works on OpenBSD. The mplayer program works on OpenBSD as well. It took a few minutes to come up with and verify that list. The list grows much larger when you include FreeBSD, since more people seem to use it."
Huh, why are you listing software developed on and for linux? I asked for examples of people writing code for solaris or BSD that linux users have to fix to get working, since you claim that happens too.
"Scarcely, FreeBSD has everything that WINE needs to run."
So do openbsd and netbsd. It was alot of work to get wine running on freebsd, dismissing the work those people did won't make it dissapear.
"When OpenBSD supports everything that WINE currently needs, it won't be as difficult so much as potentially time consuming given the size of the code"
It already does support everything wine needs. Its still as difficult to port right now as it was yesterday.
"A cursory look into the issue shows that kernel level thread support is currently holding back the OpenBSD port, which isn't a WINE issue as much as an issue for OpenBSD threads."
A cursory look into the website you mean. OpenBSD has kernel threads. Rather than reading an incorrect note someone who didn't try porting wrote, try compiling the code. You will see it has nothing to do with kernel threads at all. Hell, I've had wine developers tell me that OpenBSD is fully supported and the latest wine works on it fine. They don't seem to pay much attention to what works and why.
"WINE can be run on other BSD systems until then."
No, just freebsd and the freebsd compatible systems (PC BSD and such). It doesn't run on netbsd either.
"It's software that now has a FreeBSD port."
Has a freebsd port because of freebsd users. It was and is developed on and for linux, and requires 3rd parties to fix it. If the developer of the software made sure it ran on freebsd, then it wouldn't be linux software. But if the developer just develops it on and for linux, and then 3rd parties have to fix it for other OSs, then its clearly targetting linux, like I said, and contrary to the original posters blately incorrect statement.
"Your insistence in calling it Linux software is where we disagree and will continue to do so. Unless it accesses a kernel specific resource, there's nothing Linux particular about it. There may be GNUisms, or code that leans toward SysV, but that's a different issue."
Linux isn't just a kernel, its also an OS. Wether you like the fact that linux is a name for 2 things or not won't change that. Even all the indignation that RMS can muster has not and will not change this. Using glibc functionality is targetting linux (the OSs), as that is what linux (the OSs) includes with linux (the kernel).
I don't draw that line, the people creating OSs draw those lines for their OSs. What on earth does this have to do with anything? I just asked a simple question. BSDs already have userlands, they come with shells and all the usual assortment of command line utilities, and package management to add more stuff. What is the point of using the awful GNU/random userland that debian and gentoo subject you to on top of a BSD kernel? There's no need to wait for a debian or gentoo userland to be working nicely on a BSD kernel since each of the BSD kernels comes with a better userland anyways. If you have an answer to that question feel free to speak up, but asking me random questions that have nothing to do with anything isn't clarifying things at all.
Yes, I shouldn't be assuming anyone on slashdot has common sense, my bad.
Wine as it exists today smart ass, not a version from 1999 that can't run any windows software at all.
"For Free and Open Source software, sure it does."
Name some examples then. There's tons of open source code that is targetted directly at linux. There is very little targetted at any other unix. I know several people who develop exclusively on solaris or their BSD of choice, and all of them have linux and either solaris or a BSD (whichever they aren't using obviously) installed in a VM of some sort for testing. I don't know of anyone who develops primarily on linux and does the same. They all just assume real unixes are scary and hard to use and so rely on other people to fix their code for them.
"It works on FreeBSD, which is a BSD and not Linux. Tell me then, why is it so difficult to get it running on OpenBSD?"
Because FreeBSD people took the time to fix it for FreeBSD. And they keep taking that time over and over and over again since the wine developers keep writing more linux only code.
"Is WINE FreeBSD software as well?"
No, its linux software that dedicated FreeBSD fans have ported.
"probably not even as difficult as you think."
Probably exactly as difficult as I think, I tried. Now you go try instead of pretending its so easy. You are insulting all the people who spent the time getting it working on FreeBSD with your ignorance.
"I'm not pretending; I'm telling you you're complaining about fringe platforms being ignored that do not in themselves define UNIX"
Yes, you are pretending. I have made it very clear over and over and over again what I am saying, and you are ignoring that, pretending I am saying something else, and arguing against that. You don't need me for that, go argue with your made up pretend me on your own. You can grab an old sock and make a me puppet to argue with if you can't respond to what I say instead of what you want me to say. Just make sure you give the me sock puppet a nice moustache.
"If you're saying that there are a lot of GNU applications that never get ported to your favorite platform"
I didn't say they never get ported, I said THEY NEED PORTING. Much of it is ported, some is not. Either way its totally irrelivant, the point is that it needed ported to begin with because the authors wrote it for linux + gcc + glibc. What the hell kind of mental block is crippling your ability to grasp this simple concept?
"Most programmers I know go with the current ANSI C standard as supported by their compiler and OS libraries."
No, they ignore the C standard and go with gcc + glibc.
"You're complaining that a lot of software is written on Linux and somehow never gets ported to other platforms."
This is the last time I will say this, obviously you are choosing not to listen because you like strawman arguments. I am making this as clear as I possibly can, please read this instead of making up more bullshit and pretending I said it:
PEOPLE WRITE SOFTWARE FOR LINUX.
Are we clear? That is what I am saying. That is all I am saying. I am not complaining about anything except your refusal to stick to what I am saying instead of what you want me to be saying. The original poster claimed that people do not write software for linux, but again, and as you are clearly aware of since you've admitted it over and over:
PEOPLE WRITE SOFTWARE FOR LINUX.
It is a correction of the incorrect post. Nothing more. Stop reading anything else into it, everything else is in your imagination. Its unfortunate that in trying to demonstrate to you that PEOPLE WRITE SOFTWARE FOR LINUX, you focus in on all sorts of details in the examples and ignore the point, that PEOPLE WRITE SOFTWARE FOR LINUX.
"Also, the spaces were supposed to go in front, I didn't think I needed to spell that out."
And that still does not lead to a security hole. You can't even make up an example where you shouldn't use strlcpy? You're entire argument is that because strlcpy is not meant to be used for everything it should not be used at all. memcpy is not meant to be used for everything either, yet there it is. Just because you can use a function wrong, does not mean it adds no value since you can also use it right.
"strncpy is not meant for general string manipulation"
Yes it is, it was meant as a bounded strcpy. It does this task very poorly, hence strlcpy replacing it. Why do you think its named strncpy? It has nothing to do with your bizzare record format nonsense, its strcpy with a length.
And you can see strncpy in use all over the place, grep the source tree of most open source C programs and you will see strncpy being used.
"But as you seem to think that anyone not agreeing with you must be an idiot,"
No, I made it quite clear that failing to understand someone else's opinion, presenting it as your own in an incorrect and obviously stupid example, while pretending to be an authority on secure C programming makes you an idiot. Ulrich Drepper thinks strlcpy is bad too, but he at least knows C and is capable of making up examples where you shouldn't use strlcpy. Hence he's not an idiot, just a liar for pretending that's why he won't include it when its really his NIH complex where he wants to push his non-standard mempcpy function over someone else's non-standard strlcpy function. Obviously he has no problem with the concept of such a function, or including non-standard functions or else mempcpy wouldn't be in glibc. He just wants people to use his non-standard extension over the one that looks nicer and is already widely adopted.
"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."
To recap: strncpy fails to guarentee NULL termination and doesn't let you check truncation. strlcpy solves these problems and is faster than strncpy. Use strlcpy instead of strncpy, its 51 lines long including the license, you can use it in any project. Nobody with any background in secure C programming denies the usefulness of strlcpy/cat. The only people who argue against strlcpy/cat are people with an agenda of pushing their strncpy alternatives, or people like you who just regurgitate those people's rhetoric without understanding it. Even systems without strlcpy like plan 9 include some function to replace strncpy securely, showing that wether or not you want the particular implimentation that is strlcpy, there is a need and desire to have a secure strncpy replacement.
"That it is also a BSD'ism is the fact that got lost somewhere in this thread."
First of all, its not a BSDism. All the BSDs are smart enough to include it in their libc, yes. But so do Solaris and Windows services for unix. Just because a couple programmers from one of the BSDs made the functions initially, doesn't make it a BSDism. It would be a BSDism if it only was found in BSDs.
Second, the fact that people who use it include it in their code got lost on you. Its not relying on a BSDism if you include the function in your code, use your head. That's like saying that using daemon() is a relying on a BSDism, when in fact most unix systems have daemon(), and you can can include it for those that don't. Or that using sockets is relying on a BSDism. A ton of current unix implimentations came from a BSD initially, its only a problem if you blindly assume every system is the same.
I never said people shouldn't use non-standard extentions like gnuisms, just that they should not RELY on them. So if you include the functions in question, you are all good. Pretty simple huh?
"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."
Anyone can grep -r strlcpy in the kernel source tree too. Actions speak louder than flamewars, especially considering Linus' tendancy to flame people because they are smarter than him, then quietly do what they said in the background because he knows they are right.
"Until the next someone uses some sort of valid filler (like a spaces, or something else) to achieve that chopoff. Boom, security breach."
Boom, wtf are you talking about? If the max table length is 255 lets say, and someone puts a 255 char table name in plus a bunch of spaces which we truncate, how is that any different from them just putting in the 255 char table name to begin with? This has nothing to do with anything, why do you think its a security breach?
"Yeah, I should've checked the return value, but what then would I have done? Raised an error?"
Gee, what do you think you should do when you get a table name longer than the max length of a table name? Sounds like an error to me.
"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."
We all don't know that. If you don't like C then don't use it. But refusing to include useful C functions because you don't like that they behave consistantly with the rest of C is moronic at best.
"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."
And fixed buffers make perfect sense, because a tons of things have a fixed max size, like table names. Your example is a perfect example of why strlcpy IS GOOD. You would need to recreate strlcpy's behaviour to make your example correct and secure.
"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."
Yes, it is quite informative. It shows both how ignorant Linus is, and how he likes to flame people for being better programmers than him, while in the background copying the same thing he is flaming them for. That's not openssh's code being picked apart, its a typo'd version of a few lines being bitched about by idiots who haven't actually looked at the code. Considering the security track records of linux and openbsd, Linus has no place to be telling openbsd developers about secure coding. I will trust history over a bizzare fetish where you have convinced yourself that Linus knows anything about secure programming.
"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?"
BECAUSE strlcpy IS A REPLACEMENT FOR strncpy! Are you retarded? I bring it up because its 100% relevant, it is in fact the whole fucking point. strlcpy is a correct, secure and effecient replacement for strncpy, so obviously it is to be used instead of strncpy. In situations where you are dealing with fixed size buffers. And despite ignorant, memory exhaustion error filled code that tries to show otherwise, this is very often the case. I was right to insult you in the first post, I apologize for not being more of a dick in the second post. You are a fucking idiot.
"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."
And so you gave an example where it makes no sense at all to realloc, and where it would slow down the code and create security holes if you did? TABLE NAMES HAVE A MAX LENGTH. THEY ARE FIXED SIZE. Why do you think using a function that operatings of fixed length strings whe
"Most definitely not. The vast majority of code out there gets developed for one OS (particularly Win32 and embedded operating systems, but it happens enough in the *NIX world too) and runs there"
We're talking about open source projects remember? Seriously, every project I know developed primarily on a non-linux unix is tested and fixed for linux at least, and usually BSD and solaris as well. This doesn't occur very often going the other way.
"Not to be rude, but really, why would most people care?"
Not to be rude, but are you incapable of grasping simple concepts? I DO NOT CARE. You said its trivial to port software, I pointed out an example of how non-trivial it can be. Why do you persist in pretending I give a shit about porting any given piece of software? I have made it very clear several times now that I am simply correcting the false assertion that people don't develop for linux. They do.
"GLIBC is part of the GNU system and uses GNU conventions. That's about as close to a standard as one can get in the current fragmented UNIX environment"
No, there is the C standard actually.
"In all likelihood, it's because noone cares enough to do anything about it. Do you?"
No, I do not. Try to read what you are replying to.
"I'm not saying there aren't any linuxims in KDE, because there are."
Right, that's the point. It is written for linux, and then users of other systems have to fix it for their systems. So its not a case of linux distros using KDE and Gnome as kotj.mf thinks. Quite the opposite, it is a case of Gnome and KDE developers using linux.
"Not really"
Yes really. People develop for linux. He said people don't develop for linux. But that's exactly what they do. Its very simple.
"By your logic, if people wrote software for Solaris then they were writing code not for UNIX but for Solaris only; In order to compile for SunOS 4.x, HPUX, AIX, IRIX, Tru64, Free/Net/OpenBSD, and other UNIX systems there would need to be changes made because each system is a bit different."
Right, they would be devloping for solaris. But people don't do that. People who develop primarily on Solaris or a BSD of their choice are almost always nice enough to test their software on other free OSs and make sure it works. I can understand people not making sure their stuff works on AIX or HP-UX or whatever, but solaris and BSDs and linux and darwin are all free. There's really no reason not to make your software work on them besides laziness.
"but I've built software for many systems that weren't necessarily the original coder's targets and it's not that difficult."
That depends on the software. Trivial software tends to be trivial to port. Go get wine working on openbsd and tell me how easy that is.
"You're simply trying to pin Linux and GNU systems down as the only odd ones out there, whereas most systems have a variety of small differences."
No, it has nothing to do with linux being the odd one out, its just popular. And I am not pinning anything, I am simply correcting a completely wrong statement. It would be just as dumb to develop software for netbsd/arm only and not bother testing it out on other platforms. But that's not what people do.
"The most differences for that matter are probably between the BSDs and SysV based systems. Take a look at the output of autoconf's "configure" on multiple UNIX flavors and you'll see what I mean; even SysV systems can have different numbers of arguments for various library functions."
No need, I actually write unix software in C. I know there's alot of differences. And I test out my code on a wide variety of hardware and software platforms before making releases so that I don't let BSDisms creep into my software. I am not sure why you keep trying to convince me of things I am already aware of, what does any of this have to do with the original post? Yes, people do develop directly on and for linux, with no regard to other OSs. That is exactly what happens in many cases. Hence the original post claiming people develop for posix plus nonexistant "standards" is wrong. The part about people coding for glibc is correct however, he just seems to mistakenly think glibc is a standard.
"Nonsense! Get out from behind that rock and see the real world!"
I'm sure the people who spend hours making it so you can run KDE on freebsd really appreciate your gratitude. I am not trying to trash KDE, I don't even use it. I am just saying that yes, it is in fact developed by linux users, for linux users, on linux machines. Then BSD people fix it. KDE people are nice enough to take the patches, but they still developed linux software, and BSD people fixed it. This nonsense claim that people are developing cross platform code that works out of the box everywhere is crazy.
"Go look at those patches you talk about. They are either standard bug/exploit fixes, changes to hardcoded file paths and names, or they're changes to default values."
I did look, plenty of them are fixing linuxisms. Even little things like ifdefs being in the wrong places so that the code doesn't compile if LINUX_ONLY_FEATURE_X is not defined.
There is no invalidating his point, he is simply wrong. What he said is incorrect.
"It is very unlikely that developers follow Linux only."
Yes, that is exactly what most of them do. They use linux, and develop on and for linux.
"They support some well documented and mature standards like Gnu Libc, X window and POSIX, among others."
Glibc is not a standard, and the fact that people do program for it is "following linux only".
"Infact, for example, most of the desktop software can be compiled and run under almost all OS that comply to those standards."
In fact, most of it cannot. It has to be altered to work on all the other OSs. Because it is written for linux.
See, he is wrong, and clearly you know that since you've pointed out reasons why people write linux code. How easy or hard it is to fix that code is both irrelivant, and varies tremendously depending on the code.