Now, if patents couldn't be granted to corporations AT ALL, then I'd vote for it. Of course, that would also be the day that coporations no longer put money in political pockets, so I'm not holding my breath...
I will certainly agree that it's the most *common* reason to do marketing... But it's still not the only one. OSS folks, IMHO, tend to go more for the "recognition" aspect.
As to reviews, I'll be curious to hear them as well. Unfortunately, I don't have enough time to dig into this stuff -- hence the reason that my workhorse box runs a three year old version of debian instead of the latest and greatest...
Yah, I agree 100% with just about everything you've said there... I've been thinking about the desktop Linux thing for a long while, and I'm rapidly coming to the conclusion that the only real solution is to take the term 'Linux' out of distribution names.
RedHat is RedHat. Debian is Debian. After all, if you built an OS around the Windows NT kernel, but it looked and acted very differently from Windows, would you still want to call it Windows? Maybe that's the real core issue...
The problems with various internet protocols (including the underlying IPv4 protocol!) have been known for YEARS, and have been screamed about by us geeks for YEARS. Nothing has happened, and there is a reason for this.
If you want to change the standard, you first must convince people to use your new standard. Now if someone comes up with a shiny new email feature that everyone thinks they *must* have, and it happens to be based on an existing protocol, and there's no way it will work with SMTP, well......then you might have something.
Personally, I'd consider "no spam" enough of a feature, but I think I'm in the minority, unfortunately...
I probably should've been more careful with my implications there -- I wasn't meaning to imply that they'd succeeded in their efforts;) I haven't installed a deb system in a while (haven't had to, the last one's still happy), but it wasn't as easy as it should've been either the last time I did. OpenBSD certainly has the perception of being harder to use, though, however innacurate that perception may or may not be.
I think, unfortunately, that's largely the state of Linux -- until we pull together as a community and define some standards for how things are done in userspace on a "Linux" distribution, it'll probably stay that way. The question is, can open source developers put aside their egos and agree on stuff like that? Freedom such a handy buzzword;)
Personally, I'd like to see us do a "desktop Linux" standard that has basically nothing to do with the Unix userspace model -- there's some real power in options that opens the system up to. Of course, slashdotters would probably not like it much, but if ya wanna take out the top dog (eg, Redmond), you have to realize that noone outside of the Unix community really wants to know what/usr/sbin is for, or why there are so many directories cluttering their disk by default...
Back on topic, though, I agree about needing to put work into it -- sorta like the comment I made in another thread on this story about programmers not being able to take shortcuts if they want to design secure systems. "Trusted" operating systems are the equivalent of "Java" in that case;)
This kind of naive attitude is why we have so much bloody buggy software. While changing programming languages may reduce a certain class of errors, it will never, ever, ever result in security. It can't. The programming language can't prevent a programmer from being stupid.
If you want security, you'll actually have to do the one thing that few programmers actually take the time for in this industry: don't take shortcuts. Plan your software, plan your security model, code it carefully, have it peer reviewed (carefully, two or three times), etc...
Then you'll have a *hope* of security.
That being said, security in software is all a carefully crafted illusion anyway.
The reason "why not" is actually stated as one of the project's motivations: they want to make running a "secure" system easy for the normal user. OpenBSD is definitely a reasonably nice system, but easy it is not. Unless something has changed in the last three or four years, anyway...
I was under the impression that objects stored on the heap were to be stored in chunks of memory that was dynamically allocated and released under the explicit control of the programmer...
That's typically the usage, yeah -- but the details of dynamic memory allocators aren't typically handled by the operating system, but rather by libraries linked to the application (at least under Unix -- I'm not sure where the line is drawn under Windows, though I believe it actually has granular memory allocation system calls. I won't make any claims there, I'm not enough of a Windows internals geek).
The stack doesn't really do "reference counting", though. It's just a moving pointer (think the usual dish dispenser imagery). The way most compilers use it (based on my understanding, which is admittedly murky on this point), they copy the stack pointer into the BX register (this is called the frame pointer) when entering a function. New locals are put on the stack just by subtracting the size of the object from the stack pointer; when the function returns, the original stack pointer is restored from BX, automatically "deallocating" any stack space that was used in the function.
Dynamic allocators are much uglier. Under Unix, you only get the brk() system call, which will add or remove usable memory to or from the process's address space. The application then has to build a table somewhere in that memory, and use it to chunk out the free space to the rest of the application whenever malloc() is called. This is a hairy subject -- things like arena fragmentation get involved, and I don't like thinking about stuff like that...:)
Under Linux, IIRC, the stack actually does reside in the process's data space as well. I'd have to look this up to be accurate, but I think the diagram below is a fairly reasonable representation of the way Linux's process virtual address space is laid out:
[ this looked much prettier before the Slashdot lame(ness) filter kicked in... --ed.]
The 3GB (might be 2GB, not sure) through 4GB area is unused to make things easier for the kernel in accessing userspace data (it can just use a different segment register when accessing user data than it does when accessing kernel data, but the offset pointer doesn't have to be modified). The kernel itself would theoretically use virtual addresses starting at 3GB in this scenario.
The process image and data are obvious; accessing unused space results in SIGSEGV. The stack lives at the top; I'm not sure how Linux does things here, but with the stack at the top it could be automatically grown downward (hence the reason stack pointers are subtracted from instead of added to when you're looking for the next location) whenever something faults into the unused space while trying to access the stack.
All of this, though, is entirely implementation dependant -- Linux does things this way because it's much easier to handle (and AFAIK gcc doesn't support a segmented memory model to boot -- if it does, someone tell me, I have uses for that!). If we get into segments, the compiler (or assembly programmer) has to be aware of which segment register is used for what, etc. etc. etc...
Hmmm. I seem to be rambling. =)
As for the gambling thing, there's unavoidable gambling and there's recreational gambling -- I was talking about the recreational sort;)
As for the other thing, my coworkers tend to refer to any discussion refuting their point of view (no matter how obviously errant their point of view is, eg. "we live on Mars") as an argument -- I guess I've just gotten used to it. Jeesh, I need to get out of this industry and go back to coding as a hobby;) THEN I can discuss again!
If anyone wants to give a more technically accurate description of (a) stack frames or (b) Linux kernel memory architecture, I'd be most interested in hearing it.:) I've gathered all of this through poking around at Intel documentation, Linux source, and too many years of coding, so some of it may be inaccurate...
As a followon, I just realized I could've explained this much more simply: Stacks have entirely to do with a data object's life cycle, not with its size.
Of course, why I'm arguing with someone on Slashdot is probably a far more pertinent question than the difference between stacks and heaps =)
1. Stack memory is limited, heap memory can increase by adding more memory (up to a limit.) Core RAM is limited (currently to 4G) but you can expand the RAM drive by adding more 4G cards.
Stacks can, in fact, expand to fill available memory in an average system. The stack is nothing more than a defined location in memory with a specific access paradigm -- just another data structure, in other words. Hardware wise, it's not much different from heap memory, except that processors tend to have specialized instuctions, registers, and modes supporting it because it's so incredibly useful. Check out the Intel documentation on how Protected Mode works. Did you know that you could have a 4GB stack if you wanted to?
2. The data can't overflow from the stack and into the heap. Ditto expanding the system with the RAMdrive, it adds memory but doesn't increase the space of CPU usable memory.
Depends on how the OS sets up the address space. Stacks can, in fact, overflow into the heap if you're using a flat linear address space for everything. It's all in how you map phsyical memory to the logical address space.
3. By putting your big objects (swapping them out) onto the heap (out to the swap file on the RAM drive) you can get more out of the limited memory of the stack (can mo'better apply the 4G of RAM that the CPU can address, and quickly move data in and out of that space to the swapfile located on the RAM drive.)
1. See my first point about maximum stack size.
2. Intel CPU's can access more than 4GB of memory. You could even have a system with 4GB of "heap" and 4GB of "stack". The reason why Linux and Windows limit applications to this 4GB boundary on x86 processors is because, well, "segmentation is hard".
4. Given the ratio of C coders to people that install Windows and know what a swapfile is... I was gambling that I could probably slide this one under the wire. Busted! Guess not.
I don't gamble. Stack usage is entirely a concept, and has no real relation to hardware support other than convenience functionality provided by the processor. Apples and oranges.
Swap access is almost, but not quite, exactly unlike anything to do with the concept of a stack vs. a heap. In stack vs. heap, the only difference (at least in a modern machine, I'm not quite enough of an oldschool geek to know if any machines actually had hardware stacks 'back in the day') is where the data is stored -- access times don't necessarily change. In a paging operation, there is a *significant* speed difference (context switches, memory copies, yadda yadda).
Last time I heard, a n(yi)bble was 4 bits. Has something changed in the last fifteen years? (And yes, there is some precedent to say that it varies, but 4 bits is the most common usage...)
We recently had a discussion at work related to code indentation. The question at hand is this: how many time have you picked up someone else's code and it seems terribly poorly indented, until you realize that they had their tabstops set for 4 characters?
Non-ANSI, to be sure, but it happens. Programming with significant whitespace will continue to be impractical, at least for me, until computers force tabs to be N characters accross the board (which will never happen).
Besides, having blank space mean something is just evil. But that's neither here nor there.
Writing code that works is not hard. I've been doing it for the last 7 years. It's actually fairly easy -- *IF* you have the knowledge required to write the code you've sold yourself as being able to write.
The problem here is that a fairly large segment of the professional programmer population is fairly ignorant. They don't understand basic issues in performance, security, scalability, and other areas. If they did, I'd venture to say (and even without being totally anti-MS) that fewer people would use NT, since it's a far less Real Programmer friendly OS. But the latter is beside the point, and MHO.
The point is that the real issue isn't "true security," it's "common sense." A goodly percentage of programmers out there don't do the common sense things that a -real- programmer, someone who truly understands the things they're writing, does.
Cryptography and its uses should be something people think about -after- the common-sense security issues have been dealth with.
I think what bothers me the most about the whole issue isn't so much that the RIAA wants to protect itself. That I can understand, being a business oriented individual. But then, consider this:
I got bored, so I built my own MP3 player that has a few nifty features that I get a rise out of. No biggie. I don't typically swipe music. I buy it and encode it. I'm probably not typical in this respect, but that's me.
I then take this reasonably sized collection of legally owned music and play it on my nifty MP3 player. No big deal, at least for me.
But if the RIAA has its way...
...am I, as a hobbyist, going to realistically be able to do what I'm doing now?
I don't like the idea of that power being taken from me. Much like many others here, I would gladly pay the artist directly for songs - it's better than buying CD's, in fact. But I really don't care that CD's cost $18 a pop. I care that I can listen to them the way -I- want to listen to them, and the technologies that the RIAA is proposing (with the presumed goal of killing MP3) are threatening that ability.
Slashdot Mirror
Good point about the legal stuff. Hmmmmmm... Maybe we should make corporations not allowed to have lawyers at all, either! ;-)
Unfortunately, that only stops the individual.
Now, if patents couldn't be granted to corporations AT ALL, then I'd vote for it. Of course, that would also be the day that coporations no longer put money in political pockets, so I'm not holding my breath...
--ZS
I will certainly agree that it's the most *common* reason to do marketing... But it's still not the only one. OSS folks, IMHO, tend to go more for the "recognition" aspect.
As to reviews, I'll be curious to hear them as well. Unfortunately, I don't have enough time to dig into this stuff -- hence the reason that my workhorse box runs a three year old version of debian instead of the latest and greatest...
Yah, I agree 100% with just about everything you've said there... I've been thinking about the desktop Linux thing for a long while, and I'm rapidly coming to the conclusion that the only real solution is to take the term 'Linux' out of distribution names.
RedHat is RedHat. Debian is Debian. After all, if you built an OS around the Windows NT kernel, but it looked and acted very differently from Windows, would you still want to call it Windows? Maybe that's the real core issue...
--ZS
Marketing is not about getting rich. Marketing is about attempting to make yourself or your product a household name.
Money is not the only reason for doing such things, you know.
The problems with various internet protocols (including the underlying IPv4 protocol!) have been known for YEARS, and have been screamed about by us geeks for YEARS. Nothing has happened, and there is a reason for this.
...then you might have something.
If you want to change the standard, you first must convince people to use your new standard. Now if someone comes up with a shiny new email feature that everyone thinks they *must* have, and it happens to be based on an existing protocol, and there's no way it will work with SMTP, well...
Personally, I'd consider "no spam" enough of a feature, but I think I'm in the minority, unfortunately...
--ZS
I probably should've been more careful with my implications there -- I wasn't meaning to imply that they'd succeeded in their efforts ;) I haven't installed a deb system in a while (haven't had to, the last one's still happy), but it wasn't as easy as it should've been either the last time I did. OpenBSD certainly has the perception of being harder to use, though, however innacurate that perception may or may not be.
;)
/usr/sbin is for, or why there are so many directories cluttering their disk by default...
;)
I think, unfortunately, that's largely the state of Linux -- until we pull together as a community and define some standards for how things are done in userspace on a "Linux" distribution, it'll probably stay that way. The question is, can open source developers put aside their egos and agree on stuff like that? Freedom such a handy buzzword
Personally, I'd like to see us do a "desktop Linux" standard that has basically nothing to do with the Unix userspace model -- there's some real power in options that opens the system up to. Of course, slashdotters would probably not like it much, but if ya wanna take out the top dog (eg, Redmond), you have to realize that noone outside of the Unix community really wants to know what
Back on topic, though, I agree about needing to put work into it -- sorta like the comment I made in another thread on this story about programmers not being able to take shortcuts if they want to design secure systems. "Trusted" operating systems are the equivalent of "Java" in that case
If you want security, write in Java.
This kind of naive attitude is why we have so much bloody buggy software. While changing programming languages may reduce a certain class of errors, it will never, ever, ever result in security. It can't. The programming language can't prevent a programmer from being stupid.
If you want security, you'll actually have to do the one thing that few programmers actually take the time for in this industry: don't take shortcuts. Plan your software, plan your security model, code it carefully, have it peer reviewed (carefully, two or three times), etc...
Then you'll have a *hope* of security.
That being said, security in software is all a carefully crafted illusion anyway.
The reason "why not" is actually stated as one of the project's motivations: they want to make running a "secure" system easy for the normal user. OpenBSD is definitely a reasonably nice system, but easy it is not. Unless something has changed in the last three or four years, anyway...
Two words: marketing buzzword.
If people would design software that doesn't do things the most inefficient way possible, maybe that wouldn't be the case....
It's amazing how much you can do with 1MB or so of memory. It really is. But you wouldn't know it by the way today's corporate code monkey uses it.
That would be mmap(). nmap is a command line network toy.
--ZS
I was under the impression that objects stored on the heap were to be stored in chunks of memory that was dynamically allocated and released under the explicit control of the programmer...
:)
;)
;) THEN I can discuss again!
:) I've gathered all of this through poking around at Intel documentation, Linux source, and too many years of coding, so some of it may be inaccurate...
That's typically the usage, yeah -- but the details of dynamic memory allocators aren't typically handled by the operating system, but rather by libraries linked to the application (at least under Unix -- I'm not sure where the line is drawn under Windows, though I believe it actually has granular memory allocation system calls. I won't make any claims there, I'm not enough of a Windows internals geek).
The stack doesn't really do "reference counting", though. It's just a moving pointer (think the usual dish dispenser imagery). The way most compilers use it (based on my understanding, which is admittedly murky on this point), they copy the stack pointer into the BX register (this is called the frame pointer) when entering a function. New locals are put on the stack just by subtracting the size of the object from the stack pointer; when the function returns, the original stack pointer is restored from BX, automatically "deallocating" any stack space that was used in the function.
Dynamic allocators are much uglier. Under Unix, you only get the brk() system call, which will add or remove usable memory to or from the process's address space. The application then has to build a table somewhere in that memory, and use it to chunk out the free space to the rest of the application whenever malloc() is called. This is a hairy subject -- things like arena fragmentation get involved, and I don't like thinking about stuff like that...
Under Linux, IIRC, the stack actually does reside in the process's data space as well. I'd have to look this up to be accurate, but I think the diagram below is a fairly reasonable representation of the way Linux's process virtual address space is laid out:
0 -> 3GB
|image|data|unmapped address space|stack|
[ this looked much prettier before the Slashdot lame(ness) filter kicked in... --ed.]
The 3GB (might be 2GB, not sure) through 4GB area is unused to make things easier for the kernel in accessing userspace data (it can just use a different segment register when accessing user data than it does when accessing kernel data, but the offset pointer doesn't have to be modified). The kernel itself would theoretically use virtual addresses starting at 3GB in this scenario.
The process image and data are obvious; accessing unused space results in SIGSEGV. The stack lives at the top; I'm not sure how Linux does things here, but with the stack at the top it could be automatically grown downward (hence the reason stack pointers are subtracted from instead of added to when you're looking for the next location) whenever something faults into the unused space while trying to access the stack.
All of this, though, is entirely implementation dependant -- Linux does things this way because it's much easier to handle (and AFAIK gcc doesn't support a segmented memory model to boot -- if it does, someone tell me, I have uses for that!). If we get into segments, the compiler (or assembly programmer) has to be aware of which segment register is used for what, etc. etc. etc...
Hmmm. I seem to be rambling. =)
As for the gambling thing, there's unavoidable gambling and there's recreational gambling -- I was talking about the recreational sort
As for the other thing, my coworkers tend to refer to any discussion refuting their point of view (no matter how obviously errant their point of view is, eg. "we live on Mars") as an argument -- I guess I've just gotten used to it. Jeesh, I need to get out of this industry and go back to coding as a hobby
If anyone wants to give a more technically accurate description of (a) stack frames or (b) Linux kernel memory architecture, I'd be most interested in hearing it.
--ZS
As a followon, I just realized I could've explained this much more simply: Stacks have entirely to do with a data object's life cycle, not with its size.
Of course, why I'm arguing with someone on Slashdot is probably a far more pertinent question than the difference between stacks and heaps =)
--ZS
1. Stack memory is limited, heap memory can increase by adding more memory (up to a limit.) Core RAM is limited (currently to 4G) but you can expand the RAM drive by adding more 4G cards.
... I was gambling that I could probably slide this one under the wire. Busted! Guess not.
Stacks can, in fact, expand to fill available memory in an average system. The stack is nothing more than a defined location in memory with a specific access paradigm -- just another data structure, in other words. Hardware wise, it's not much different from heap memory, except that processors tend to have specialized instuctions, registers, and modes supporting it because it's so incredibly useful. Check out the Intel documentation on how Protected Mode works. Did you know that you could have a 4GB stack if you wanted to?
2. The data can't overflow from the stack and into the heap. Ditto expanding the system with the RAMdrive, it adds memory but doesn't increase the space of CPU usable memory.
Depends on how the OS sets up the address space. Stacks can, in fact, overflow into the heap if you're using a flat linear address space for everything. It's all in how you map phsyical memory to the logical address space.
3. By putting your big objects (swapping them out) onto the heap (out to the swap file on the RAM drive) you can get more out of the limited memory of the stack (can mo'better apply the 4G of RAM that the CPU can address, and quickly move data in and out of that space to the swapfile located on the RAM drive.)
1. See my first point about maximum stack size.
2. Intel CPU's can access more than 4GB of memory. You could even have a system with 4GB of "heap" and 4GB of "stack". The reason why Linux and Windows limit applications to this 4GB boundary on x86 processors is because, well, "segmentation is hard".
4. Given the ratio of C coders to people that install Windows and know what a swapfile is
I don't gamble. Stack usage is entirely a concept, and has no real relation to hardware support other than convenience functionality provided by the processor. Apples and oranges.
--ZS
Swap access is almost, but not quite, exactly unlike anything to do with the concept of a stack vs. a heap. In stack vs. heap, the only difference (at least in a modern machine, I'm not quite enough of an oldschool geek to know if any machines actually had hardware stacks 'back in the day') is where the data is stored -- access times don't necessarily change. In a paging operation, there is a *significant* speed difference (context switches, memory copies, yadda yadda).
Last time I heard, a n(yi)bble was 4 bits. Has something changed in the last fifteen years? (And yes, there is some precedent to say that it varies, but 4 bits is the most common usage...)
--ZS
What I wanna know is, where do I get a plasma ball that big? It would look cool in my living room...
We recently had a discussion at work related to code indentation. The question at hand is this: how many time have you picked up someone else's code and it seems terribly poorly indented, until you realize that they had their tabstops set for 4 characters?
Non-ANSI, to be sure, but it happens. Programming with significant whitespace will continue to be impractical, at least for me, until computers force tabs to be N characters accross the board (which will never happen).
Besides, having blank space mean something is just evil. But that's neither here nor there.
--ZS
C++, Java, and various other languages have exceptions to handle those sorts of things -- and it's far more elegant than goto's ever will be.
--ZS
US Patent #5727163: Secure method for communicating credit card data when placing an order on a non-secure network
I hate to say this, but Amazon already -has- patented taking credit card numbers over the phone. No joke. Go read the summary.
Writing code that works is not hard. I've been doing it for the last 7 years. It's actually fairly easy -- *IF* you have the knowledge required to write the code you've sold yourself as being able to write.
The problem here is that a fairly large segment of the professional programmer population is fairly ignorant. They don't understand basic issues in performance, security, scalability, and other areas. If they did, I'd venture to say (and even without being totally anti-MS) that fewer people would use NT, since it's a far less Real Programmer friendly OS. But the latter is beside the point, and MHO.
The point is that the real issue isn't "true security," it's "common sense." A goodly percentage of programmers out there don't do the common sense things that a -real- programmer, someone who truly understands the things they're writing, does.
Cryptography and its uses should be something people think about -after- the common-sense security issues have been dealth with.
--ZS
I think what bothers me the most about the whole issue isn't so much that the RIAA wants to protect itself. That I can understand, being a business oriented individual. But then, consider this:
I got bored, so I built my own MP3 player that has a few nifty features that I get a rise out of. No biggie. I don't typically swipe music. I buy it and encode it. I'm probably not typical in this respect, but that's me.
I then take this reasonably sized collection of legally owned music and play it on my nifty MP3 player. No big deal, at least for me.
But if the RIAA has its way...
...am I, as a hobbyist, going to realistically be able to do what I'm doing now?
I don't like the idea of that power being taken from me. Much like many others here, I would gladly pay the artist directly for songs - it's better than buying CD's, in fact. But I really don't care that CD's cost $18 a pop. I care that I can listen to them the way -I- want to listen to them, and the technologies that the RIAA is proposing (with the presumed goal of killing MP3) are threatening that ability.
--ZS