do you think that read and write memory protections should be the responsibility of the operating system?
how does the OS control the cpu if there's no way to tell it what and what not to do?
the "execute" flag, assuming you are talking about memory protection and not some file permission bit which is unrelated, depends on CPU support. linux supports it on x86 no better than microsoft.
if you use openbsd or pax patches, segments or other tricks are used to fake an X bit. but your assertion that ms can't implement an execute flag while linux (especially the stock kernel) can is pretty false.
NX is not an instruction at all. it's an extra bit in a page table entry, augmenting the existing read and write bits (among other). once the x86 page table format was decided, it wasn't possible to go back and add a new bit. the introduction of PAE means that the page table entries are twice as big, mostly for larger physical addresses, but an extra bit can be shaved off and used for NX.
if the linux kernel code was written correctly, it will check for the presence of NX bit support before using it, just like any other advanced cpu feature.
most of your "in the works" projects have been around for a long time. you can easily use bsd pax as tar, as openbsd has done for years. awk and sed have always been from bsd. grep, diff, and gzip replacements are newer (for being included as default) however.
outside of people who want to sprinkle some openbsd on their system after a windows partition, or people who try to install has many operating systems on one disk as possible, 1024 cylinders isn't such a problem.
how many highly scalable webservers do you know of that dual boot?
you can crash *your* sshd on the server. not the parent. so your connection closes, and everyone else's stays there, and the parent keeps listening for more.
licensing, less gpl is always better if possible. we also now maintain the tools entirely ourselves. cleanliness -- they don't even know how to indent properly.:)
in the case of grep, it was a major improvement in size of the binary (think floppy installs) because we use libc regexp, not 3 different special edition text searchers made just for grep.
linking a gpl file system into the kernel certainly makes that kernel gpl. that's fine for something optional like fp emulation, because you can rip it out. it's not fine for a file system, where you lose significant functionality, and it can't be a module if you want root on reiserfs.
saying "yeah, the kernel is bsd-licensed, except for this, that, and the other thing, which are gpl" starts a bad trend. anyway, people seem to focus on the license without considering that differences in vfs layers alone are major technical hurdle.
i think the attitude is better described as, "we have a file system that works, and we like it. we don't need to import a new file system every six months."
you can't count as high as what? four? five? and if i wanted to understand this unified linux effort better, should i install redhat, debian, madrake, gentoo, slackware, trustix, or immunix?
Slashdot Mirror
do you think that read and write memory protections should be the responsibility of the operating system? how does the OS control the cpu if there's no way to tell it what and what not to do?
the "execute" flag, assuming you are talking about memory protection and not some file permission bit which is unrelated, depends on CPU support. linux supports it on x86 no better than microsoft. if you use openbsd or pax patches, segments or other tricks are used to fake an X bit. but your assertion that ms can't implement an execute flag while linux (especially the stock kernel) can is pretty false.
NX is not an instruction at all. it's an extra bit in a page table entry, augmenting the existing read and write bits (among other). once the x86 page table format was decided, it wasn't possible to go back and add a new bit. the introduction of PAE means that the page table entries are twice as big, mostly for larger physical addresses, but an extra bit can be shaved off and used for NX.
if you take a look at map, you'll notice that san jose is kinda far away from sweden.
if the linux kernel code was written correctly, it will check for the presence of NX bit support before using it, just like any other advanced cpu feature.
the pdfs are on the web site. it's an extra bit in the pte.
most of your "in the works" projects have been around for a long time. you can easily use bsd pax as tar, as openbsd has done for years. awk and sed have always been from bsd. grep, diff, and gzip replacements are newer (for being included as default) however.
kinda funny that you ask for one giant port that includes everything you might want, and then go on to say feature creep kills all software.
outside of people who want to sprinkle some openbsd on their system after a windows partition, or people who try to install has many operating systems on one disk as possible, 1024 cylinders isn't such a problem. how many highly scalable webservers do you know of that dual boot?
you can crash *your* sshd on the server. not the parent. so your connection closes, and everyone else's stays there, and the parent keeps listening for more.
why doesn't redhat ship the same kernel i find on kernel.org?
licensing, less gpl is always better if possible. we also now maintain the tools entirely ourselves. cleanliness -- they don't even know how to indent properly. :)
in the case of grep, it was a major improvement in size of the binary (think floppy installs) because we use libc regexp, not 3 different special edition text searchers made just for grep.
yeah, like i'm going to fork out $50 for a better grep. i'm pretty happy with the free one i have now.
linking a gpl file system into the kernel certainly makes that kernel gpl. that's fine for something optional like fp emulation, because you can rip it out. it's not fine for a file system, where you lose significant functionality, and it can't be a module if you want root on reiserfs. saying "yeah, the kernel is bsd-licensed, except for this, that, and the other thing, which are gpl" starts a bad trend. anyway, people seem to focus on the license without considering that differences in vfs layers alone are major technical hurdle.
i think the attitude is better described as, "we have a file system that works, and we like it. we don't need to import a new file system every six months."
you can't count as high as what? four? five? and if i wanted to understand this unified linux effort better, should i install redhat, debian, madrake, gentoo, slackware, trustix, or immunix?
because then the bsd kernel becomes a gpl kernel.
what OS do you have that creates symlinks on msdosfs?
so now when your driver crashes, it completely hoses the kernel. i don't see that as improvement.