Hmm I probably shouldn't come over then. I have a death metal band and we have a song where we jump around (trying to look 'artistic') and yelling "DEE! SELECT! DEE! SELECT!" and then during the chorus (to break it up) we do basically the same thing, but yell "DEB! IAN! DEB! IAN!"
Oh ya sorry I misread. At first read, I thought you were one of those people that says things like "well if Linux were REALLY the second son of God, it would be able to do foo", and then you want to smack them.
Although I'm still a little lost as to what it might or might not be superior to.
More superior to what? And how is it superior to whatever you're implying it's superior to? Linux is fine, but it's not superior to much. It's just different.
Umm no, if you plotted them as altitude over time, the steep one would still be steep, and the gentle one would still be gentle. That's not to say that it's bad though. Steep learning curves are hard, but that is most definitely not a bad thing. Using like your brain and stuff you know.
OK if you're using strings for anything more complex than printing to the screen in C, you might just a retard (although I will admit that I have used C for a few things marginally more complex than printing to the screen wrt strings). Probably 99% of the languages out there are better at string processing than C is.
As for my s*printf() vs v*printf() deal: I was just kind of surprised that vprintf() would be considered any more dangerous than printf(). In fact on many platforms I would wager the bytecode of the two functions is nearly exactly the same. And plus, [v]printf() errors would kill the stack, not the buffer. Thus sprintf() and his new friend would probably be the ones to watch out for.
OK first off, I think you mean snprintf() and sprintf(), not vnprintf() and vprintf(). Secondly, strcpy() and sprintf() are very useful, and I don't find them dangerous at all.
In fact, strncpy() I'd say is one of the most useless functions described in the standard. There are contexts where strcpy() makes sense, and there are contexsts where memcpy() makes sense, but never have I found a situation where strncpy() makes sense.
snprintf() is also pretty bad BTW. Using snprintf() is so awkward that it's far easier to just use sprintf() (properly, though!).
Anyway, gets() and scanf() seem to be the worst for buffer corruption. There are many other ways to kill yourself with standard calls, but not too many that will cause buffer corruption.
IINM (the link is apparently bad), libsafe is some kind of library, which means that it would have to be included at link time. This means that you would either need the source or the objects, *not* the binaries. It would seem unlikely that one would have the objects without the source.
Wouldn't it be easier to have each of the boxes just use NFS? It seems like an enourmous waste to give them a hard drive anyway, since they're all going to have presumably the same data on them. NFS does have client-side caching you know (well maybe not on Linux, but no one uses Linux for anything serious anyway).
If you're talking about a previous poster (some months back I think), then you're right. However, that poster also plagiarised. I tracked down the initial source but couldn't find the actual name of the source, so "Source: unknown (but existent)" probably wouldn't be too useful.
While it is nice to believe that electricity somehow as something to do with "electrons" (you could have at least came up with a more plausible name), and that it can't go faster than the speed of light, that story is just not believable anymore. This usually goes hand in hand with the myth that light is somehow propagated through "photons". Nothing could be further from the truth.
The new theory is the 'reverse light theory', which states that light is simply an absence of darktrons. In fact, a full 103% (+/- 2%) of scientists now believe that the reverse light theory is the correct model.
So what does this have to do with electricity? Well since darktrons (which carry the signal in optic cables) are always being evacuated by 'light' sources, they tend to have very slow and erradic behaviour. Place a lamp by your optic cable and you'll see your latency double. Deceptitrons (aka protons), the active ingredient in copper, however, create a force field which nullifies the effect of the 'light' sources. This means that one can get theoretically unlimited speeds through a copper wire. Infinite speeds are not uncommon, and one scientist has even reached speeds of infinity plus three. Not to be outdone, a scientist in Germany is aiming for speeds of two infinity, which would most likely secure him a Nobel prize.
Many pieces of code (especially interactive ones) have copyright strings embedded in them. For example, programs like emacs show copyright information at start-up (I think). Some less interactive programs will show copyright information if you pass them an option (--version or --copyright or something).
Right now, in order for someone to have a *decent* free operating system, they pretty much to be using a Unix clone. It's pretty clear that the GNU project is only concerned with Unix (duh), but have you ever heard of or ever though of starting a free non-Unix platform?
Much of the trend in Linux and GNU software seems to be towards Windows-ising it or Mac-ising it. Wouldn't the cleaner solution be just to start a new free operating system without having to carry around all that Unix baggage?
As a side note, do you ever regret choosing to implement Unix? I seem to recall in an interview that you implied that you had little experience with Unix at the time GNU was founded, thought it was the best thing since sliced bread, and later found out that it wasn't exactly the way you thought it was.
I don't think the comparison between TV characters and gcc is really accurate.
Sure, if I were to violate the GPL and make some proprietary changes to gcc, sell it, etc., that would be bad. Similarly, if I were to take a Star Wars movie and resell that as my own, that would be bad. But creating porn from the characters of Star Wars is in a completely different arena.
A better analogy would be if I were to create porn from the "characters" of gcc. For example:
auto_demangling had a lustful look on its face as it eyed maximum_field_alignment from across the room. mfa was married, but she'd caught her husband, field, in a very comprimising situation with DECL_NAME(). She'd been looking for a way to get revenge. She'd always had a thing for cse_basic_block_end, but he was static, and thus did not have external linkage. Who knows what would have happened if they'd been in the same translation unit, but I guess it was not to be. Then again, there was that fuck-fest with warn_pointer_arith and unary_complex_lvalue.
That would probably not be in violation of the GPL.
BTW sorry for implying that all fanfics are porn. Those are only the good ones (*groan*).
Re:Oh my god, they're stealing knowledge!
on
RMS On eBooks
·
· Score: 1
Agreed, the North American post-secondary education system sucks balls (I don't know much about the rest of the world, quite possibly due to my North American pre-secondary education). The textbook "ball-and-chain" is by far the worst part of it though.
There is no reason why every university textbook on the planet has to be "revised" every two or three years (or even every year?!). For some extremely fast-moving areas, you may need a revision every few years. Note that doesn't necessarily mean that you need an entirely new $110 textbook every few years, maybe just an addendum?. But for 95% of the textbooks out there, a revision every ten or twenty years will be fine -- especially for 1st and 2nd year courses. Science textbooks (like physics) seem to be the worst for this one. They reorder the chapters, "change the questions" (chapter 14, question 31 now has a 6kg mass instead of a 15kg mass) and pretend it's a new textbook. And in order to do your assignments, you have to buy it. I don't even want to think about how many times I've heard the prof say "the old textbook was better", but department regulations still force you to buy the new one.
Grrrrr.
Re:RMS should stick to coding
on
RMS On eBooks
·
· Score: 1
That doesn't sound right. If RMS really didn't like copyrights, he'd just release everything as public domain.
This is why we used the Library GPL for the GNU C library.
Also, I don't know what version of GLIBC you're using, but:
pillo:/usr/local/src/glibc-2.1.3$ head COPYING.LIB GNU LIBRARY GENERAL PUBLIC LICENSE Version 2, June 1991
And at the top of just about every source file, too:
pillo:/usr/local/src/glibc-2.1.3/stdio$ head fgets.c /* Copyright (C) 1991, 92, 95, 96, 97, 98 Free Software Foundation, Inc. This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Et cetera. Actually, if I'm not mistaken, the GNU C library was in fact the entire point of Stallman creating the LGPL. BTW FWIW, the COPYING.LIB file is the licence for the GNU C library, not COPYING.
GNU is saying that (simply-put), you cannot link non-GPL'd code against a GPL'd library. This would be analogous to Microsoft putting something in their restrictions that says "only people named Joe are allowed to link against the MFC". Does that mean that Microsoft somehow gains ownership over all code linked against the MFC by people named Bob? No, it means that it would be illegal for people named Bob to link against that library.
This also does not mean that Microsoft would have some sort of "ownership" over the API, thus putting some sort of constraint on the Wine project. If Mesa were to be released under the GPL, does this make OpenGL illegal? If the OpenGL people were to release OpenGL under the GPL, would this make Mesa illegal? No. It means that you cannot link against that *particular implementation of the API* unless your code is GPL'd. Since Wine is a *completely different implementation* of the Win32 API, it doesn't even enter the picture.
Unless I'm blind, no one else has mentioned this. Odd.
OK straight from the GPL itself. Section 10:
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
I don't think you can state it any more plainly: ASK THE AUTHOR FOR PERMISSION.
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Since the LGPL is just the GPL with a restriction removed (i.e. it is *more* free, no matter what RMS tries to tell you), it doesn't really violate that point. However it seems to imply all over the place that you can't change the licence anyway, and in section 10 it says this explicitly, so it's kind of moot.
I don't think it's completely accurate to say that the human eye doesn't see *any* difference past 24-bit colour. I've heard that the human eye can see anywhere from 15 to 25 million colours. It's not difficult to find a two colours (usually in the greens) that differ only by one RGB value, yet you can distinctly tell the difference between them.
Anyway, 32-bit video cards were created to speed things up. It's a lot easier (and faster) to just grab and dump 32 bits than it is to grab 32 bits and then carefully slice it up so you can place it in a 24-bit buffer without corrupting it. All the one's I've ever heard of just ignore the final 8-bits, anyway. I suppose you could do cool things with those 8 bits like opacity or Z-ordering or something. Alternatively, you could try to get them to do 30-bit RGB (10 bits per channel), but that can be annoying sometimes (anyone remember 15-bit colour?). Or you could try and do 32-bit colour by doing a 10-12-10 split (anyone remember 16-bit colour?). Either way, I guess 24-bit colour is "good enough".
Slashdot Mirror
Hmm I probably shouldn't come over then. I have a death metal band and we have a song where we jump around (trying to look 'artistic') and yelling "DEE! SELECT! DEE! SELECT!" and then during the chorus (to break it up) we do basically the same thing, but yell "DEB! IAN! DEB! IAN!"
Oh ya sorry I misread. At first read, I thought you were one of those people that says things like "well if Linux were REALLY the second son of God, it would be able to do foo", and then you want to smack them.
Although I'm still a little lost as to what it might or might not be superior to.
More superior to what? And how is it superior to whatever you're implying it's superior to? Linux is fine, but it's not superior to much. It's just different.
Umm no, if you plotted them as altitude over time, the steep one would still be steep, and the gentle one would still be gentle. That's not to say that it's bad though. Steep learning curves are hard, but that is most definitely not a bad thing. Using like your brain and stuff you know.
Only on Slashdot could "it's a shame that they're dying a horrible death, but what about *me*? *pout*" be considered "Insightful".
OK if you're using strings for anything more complex than printing to the screen in C, you might just a retard (although I will admit that I have used C for a few things marginally more complex than printing to the screen wrt strings). Probably 99% of the languages out there are better at string processing than C is.
As for my s*printf() vs v*printf() deal: I was just kind of surprised that vprintf() would be considered any more dangerous than printf(). In fact on many platforms I would wager the bytecode of the two functions is nearly exactly the same. And plus, [v]printf() errors would kill the stack, not the buffer. Thus sprintf() and his new friend would probably be the ones to watch out for.
OK first of all, I either:
(a) deal with nul-terminated strings; or
(b) deal with fixed-length 'strings'.
Always. Always. Always.
(a) corresponds to strcpy().
(b) corresponds to memcpy().
If you have a 'string' which might not be nul-terminated, then it is, by definition, *not* a string.
OK first off, I think you mean snprintf() and sprintf(), not vnprintf() and vprintf(). Secondly, strcpy() and sprintf() are very useful, and I don't find them dangerous at all.
In fact, strncpy() I'd say is one of the most useless functions described in the standard. There are contexts where strcpy() makes sense, and there are contexsts where memcpy() makes sense, but never have I found a situation where strncpy() makes sense.
snprintf() is also pretty bad BTW. Using snprintf() is so awkward that it's far easier to just use sprintf() (properly, though!).
Anyway, gets() and scanf() seem to be the worst for buffer corruption. There are many other ways to kill yourself with standard calls, but not too many that will cause buffer corruption.
IINM (the link is apparently bad), libsafe is some kind of library, which means that it would have to be included at link time. This means that you would either need the source or the objects, *not* the binaries. It would seem unlikely that one would have the objects without the source.
Wouldn't it be easier to have each of the boxes just use NFS? It seems like an enourmous waste to give them a hard drive anyway, since they're all going to have presumably the same data on them. NFS does have client-side caching you know (well maybe not on Linux, but no one uses Linux for anything serious anyway).
If you're talking about a previous poster (some months back I think), then you're right. However, that poster also plagiarised. I tracked down the initial source but couldn't find the actual name of the source, so "Source: unknown (but existent)" probably wouldn't be too useful.
OK you need a bit of a schooling.
While it is nice to believe that electricity somehow as something to do with "electrons" (you could have at least came up with a more plausible name), and that it can't go faster than the speed of light, that story is just not believable anymore. This usually goes hand in hand with the myth that light is somehow propagated through "photons". Nothing could be further from the truth.
The new theory is the 'reverse light theory', which states that light is simply an absence of darktrons. In fact, a full 103% (+/- 2%) of scientists now believe that the reverse light theory is the correct model.
So what does this have to do with electricity? Well since darktrons (which carry the signal in optic cables) are always being evacuated by 'light' sources, they tend to have very slow and erradic behaviour. Place a lamp by your optic cable and you'll see your latency double. Deceptitrons (aka protons), the active ingredient in copper, however, create a force field which nullifies the effect of the 'light' sources. This means that one can get theoretically unlimited speeds through a copper wire. Infinite speeds are not uncommon, and one scientist has even reached speeds of infinity plus three. Not to be outdone, a scientist in Germany is aiming for speeds of two infinity, which would most likely secure him a Nobel prize.
No kidding. If you ask me, Troll should be +1, not -1. Seriously, would there be *any* point to Slashdot whatsoever if it weren't for the trolls?
Many pieces of code (especially interactive ones) have copyright strings embedded in them. For example, programs like emacs show copyright information at start-up (I think). Some less interactive programs will show copyright information if you pass them an option (--version or --copyright or something).
Right now, in order for someone to have a *decent* free operating system, they pretty much to be using a Unix clone. It's pretty clear that the GNU project is only concerned with Unix (duh), but have you ever heard of or ever though of starting a free non-Unix platform?
Much of the trend in Linux and GNU software seems to be towards Windows-ising it or Mac-ising it. Wouldn't the cleaner solution be just to start a new free operating system without having to carry around all that Unix baggage?
As a side note, do you ever regret choosing to implement Unix? I seem to recall in an interview that you implied that you had little experience with Unix at the time GNU was founded, thought it was the best thing since sliced bread, and later found out that it wasn't exactly the way you thought it was.
Any idea if any of them have a Shelbyville near by?
I don't think the comparison between TV characters and gcc is really accurate.
Sure, if I were to violate the GPL and make some proprietary changes to gcc, sell it, etc., that would be bad. Similarly, if I were to take a Star Wars movie and resell that as my own, that would be bad. But creating porn from the characters of Star Wars is in a completely different arena.
A better analogy would be if I were to create porn from the "characters" of gcc. For example:
auto_demangling had a lustful look on its face as it eyed maximum_field_alignment from across the room. mfa was married, but she'd caught her husband, field, in a very comprimising situation with DECL_NAME(). She'd been looking for a way to get revenge. She'd always had a thing for cse_basic_block_end, but he was static, and thus did not have external linkage. Who knows what would have happened if they'd been in the same translation unit, but I guess it was not to be. Then again, there was that fuck-fest with warn_pointer_arith and unary_complex_lvalue.
That would probably not be in violation of the GPL.
BTW sorry for implying that all fanfics are porn. Those are only the good ones (*groan*).
Agreed, the North American post-secondary education system sucks balls (I don't know much about the rest of the world, quite possibly due to my North American pre-secondary education). The textbook "ball-and-chain" is by far the worst part of it though.
There is no reason why every university textbook on the planet has to be "revised" every two or three years (or even every year?!). For some extremely fast-moving areas, you may need a revision every few years. Note that doesn't necessarily mean that you need an entirely new $110 textbook every few years, maybe just an addendum?. But for 95% of the textbooks out there, a revision every ten or twenty years will be fine -- especially for 1st and 2nd year courses. Science textbooks (like physics) seem to be the worst for this one. They reorder the chapters, "change the questions" (chapter 14, question 31 now has a 6kg mass instead of a 15kg mass) and pretend it's a new textbook. And in order to do your assignments, you have to buy it. I don't even want to think about how many times I've heard the prof say "the old textbook was better", but department regulations still force you to buy the new one.
Grrrrr.
That doesn't sound right. If RMS really didn't like copyrights, he'd just release everything as public domain.
The copyright holder can change the terms of their licence at any time they want. They cannot, however, do it retroactively.
This is why we used the Library GPL for the GNU C library.
Also, I don't know what version of GLIBC you're using, but:
pillo:/usr/local/src/glibc-2.1.3$ head COPYING.LIB
GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991
And at the top of just about every source file, too:
pillo:/usr/local/src/glibc-2.1.3/stdio$ head fgets.c
/* Copyright (C) 1991, 92, 95, 96, 97, 98 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
Et cetera. Actually, if I'm not mistaken, the GNU C library was in fact the entire point of Stallman creating the LGPL. BTW FWIW, the COPYING.LIB file is the licence for the GNU C library, not COPYING.
I think you misunderstand.
GNU is saying that (simply-put), you cannot link non-GPL'd code against a GPL'd library. This would be analogous to Microsoft putting something in their restrictions that says "only people named Joe are allowed to link against the MFC". Does that mean that Microsoft somehow gains ownership over all code linked against the MFC by people named Bob? No, it means that it would be illegal for people named Bob to link against that library.
This also does not mean that Microsoft would have some sort of "ownership" over the API, thus putting some sort of constraint on the Wine project. If Mesa were to be released under the GPL, does this make OpenGL illegal? If the OpenGL people were to release OpenGL under the GPL, would this make Mesa illegal? No. It means that you cannot link against that *particular implementation of the API* unless your code is GPL'd. Since Wine is a *completely different implementation* of the Win32 API, it doesn't even enter the picture.
Unless I'm blind, no one else has mentioned this. Odd.
OK straight from the GPL itself. Section 10:
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
I don't think you can state it any more plainly: ASK THE AUTHOR FOR PERMISSION.
Actually, from the GPL (section 6):
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Since the LGPL is just the GPL with a restriction removed (i.e. it is *more* free, no matter what RMS tries to tell you), it doesn't really violate that point. However it seems to imply all over the place that you can't change the licence anyway, and in section 10 it says this explicitly, so it's kind of moot.
I don't think it's completely accurate to say that the human eye doesn't see *any* difference past 24-bit colour. I've heard that the human eye can see anywhere from 15 to 25 million colours. It's not difficult to find a two colours (usually in the greens) that differ only by one RGB value, yet you can distinctly tell the difference between them.
Anyway, 32-bit video cards were created to speed things up. It's a lot easier (and faster) to just grab and dump 32 bits than it is to grab 32 bits and then carefully slice it up so you can place it in a 24-bit buffer without corrupting it. All the one's I've ever heard of just ignore the final 8-bits, anyway. I suppose you could do cool things with those 8 bits like opacity or Z-ordering or something. Alternatively, you could try to get them to do 30-bit RGB (10 bits per channel), but that can be annoying sometimes (anyone remember 15-bit colour?). Or you could try and do 32-bit colour by doing a 10-12-10 split (anyone remember 16-bit colour?). Either way, I guess 24-bit colour is "good enough".