Re:Warding off the inevitable "switch to Java" com
on
Secure Programming
·
· Score: 2, Interesting
Half-truths. Both C and C++ can support strings without buffer overflows through nice string libraries. It's just people don't use them as often as they should. Standard C library is a piece of crap as far as strings and type safety are concerned, not the whole language.
> But there's nothing out there where everybody would immediately agree that it's really better than POSIX.
I am sure POSIX and Unix and even maybe Windows experience is used to build better alternatives all the time, and people will agree they're better, but they still won't use them outside of small niches. I think Unix is too viral to compete with because "Worse is Better", plus the status quo effect.
Spam blockers block spam. Spam senders send spam. Attachment blockers block attachments. Email servers handle email. Virus scanners (on users' PCs) scan for viruses. HTML is for the Web, and not email. Attachments are a bad idea born out of the lack of popular and easy file exchange mechanism (no, it's not FTP). And the Slashdot crowd writes annoying comments (sometimes):). The answer to your question is of course "no".
The reason stems from the fact that people are trying to get rid of symptoms instead of the problem. Executables shouldn't be allowed to be sent in email, and end-users should scan archives for viruses after they get them. Email servers are not virus scanners.
Why bring old cruft into brand new OSes, with better ideas about doing things? On the other hand if it's an exokernel OS, a Unix subsytem can be just yet another library. It's been done.
If it were by me, and I'd write a new OS with the vast knowledge of what's wrong with Unix, and things like POSIX and GNU would be on the list of things NOT to be involved with.
This is either troll, or a pseudotroll
on
FreeBSD 5.1 Released
·
· Score: 3, Informative
You can read wscons documentation, then edit the config file, reboot and you have more virtual terminals. You obviously didn't read the docs, or you're just trolling.
Probably because even anyone proposing this in a Unix FS would get spit on. "Oh no, we're not conforming with POSIX!"; "Oh no, this is not the way Unix does it!"; "No, this just won't work with the rest of the kernel".
VMS didn't have to go through the Unix interfighting and standards compliance (which are broken in many places anyway, and stifle innovation).
ReiserFS does have a history of being unreliable. If you don't believe me, see their mailing list archives. Their stance on this was "tough, restore from the backup, what did you expect?"
Not that anyone gives a damn, but if you look at ReiserFS, it's quite an ambitious project that's a constant moving target, with many developers, and a LOT of code for a file system. It also seems to me their goal is features first, everything else later. So that's your explanation for a poor stability record for a project like this.
ReiserFS does have better performance with large directories, which is its main advantage over other file systems. Metadata journaling was added relatively recently. It's not as scalable in other uses, such as large files, which XFS was designed to handle very well. Ext2/3 is the choice right now for servers because it's relatively more reliable and stable, and simpler than the other two. With ReiserFS you often stumble into incompatibilities with other things in the kernel, such as NFS and LVM. Also, if you use ReiserFS some software which expects traditional FS semantics may require patching.
On the other hand with traditional FSes, you may need to work around the "many files" problem by hashing.
We don't need bloated hardware and software to design fast portable computers which run circles around Transmeta in speed and power consumption. We don't need commonly used bloated embedded operating systems either (yes this includes embedded forms of Unix, too). We just use a different approach. It has been demonstrated to work very well, and perhaps even offend a few people:).
I basically said Apache is harder to secure, not insecure. Though its security record could have been better.
Smaller servers are easier to secure, that's my argument. Other servers actually have security as their goal, and easy and small configuration. I mentioned fnord in my other message. Similar easy to set up servers are publicfile and mini_thttpd.
Why bother disabling Apache's functionality, when you can save time and use something which doesn't require this, and is small in size and fast in speed in the first place?
Flexibility is important. However, flexibility does not equal unnecessary bloat. History has shown bloat leads to security problems and support overhead.
It's not flamebait. There are many alternative servers available whos primary goal is security. They're easier to configure, secure, and maintain. Besides, most people don't need all the bells and wistles Apache offers.
Slashdot Mirror
Half-truths. Both C and C++ can support strings without buffer overflows through nice string libraries. It's just people don't use them as often as they should. Standard C library is a piece of crap as far as strings and type safety are concerned, not the whole language.
Tiny C Compiler already exists and works.
You never know. Who expected Unix to be adapted at all?
> But there's nothing out there where everybody would immediately agree that it's really better than POSIX.
I am sure POSIX and Unix and even maybe Windows experience is used to build better alternatives all the time, and people will agree they're better, but they still won't use them outside of small niches. I think Unix is too viral to compete with because "Worse is Better", plus the status quo effect.
Spam blockers block spam. :).
Spam senders send spam.
Attachment blockers block attachments.
Email servers handle email.
Virus scanners (on users' PCs) scan for viruses.
HTML is for the Web, and not email. Attachments are a bad idea born out of the lack of popular and easy file exchange mechanism (no, it's not FTP).
And the Slashdot crowd writes annoying comments (sometimes)
The answer to your question is of course "no".
The reason stems from the fact that people are trying to get rid of symptoms instead of the problem. Executables shouldn't be allowed to be sent in email, and end-users should scan archives for viruses after they get them. Email servers are not virus scanners.
> Well, it's not by you :)
I hope not just yet.
Why bring old cruft into brand new OSes, with better ideas about doing things? On the other hand if it's an exokernel OS, a Unix subsytem can be just yet another library. It's been done.
My bad, it's 'syscons'.
> --Dude, Reiserfs is TINY compared to XFS:
I wasn't comparing with XFS.
> Patently false. My SCSI and IDE LVM setup both use Reiserfs, and I have had no problems
Doesn't mean other people haven't had disasters with RiserFS. See the mailing list archives.
> --If you haven't tried Reiserfs lately, give it a shot. Most of the "problems" people think it has have
You can't ignore the crappy historic stability record.
If it were by me, and I'd write a new OS with the vast knowledge of what's wrong with Unix, and things like POSIX and GNU would be on the list of things NOT to be involved with.
You can read wscons documentation, then edit the config file, reboot and you have more virtual terminals. You obviously didn't read the docs, or you're just trolling.
Probably because even anyone proposing this in a Unix FS would get spit on. "Oh no, we're not conforming with POSIX!"; "Oh no, this is not the way Unix does it!"; "No, this just won't work with the rest of the kernel".
VMS didn't have to go through the Unix interfighting and standards compliance (which are broken in many places anyway, and stifle innovation).
ReiserFS does have a history of being unreliable. If you don't believe me, see their mailing list archives. Their stance on this was "tough, restore from the backup, what did you expect?"
Not that anyone gives a damn, but if you look at ReiserFS, it's quite an ambitious project that's a constant moving target, with many developers, and a LOT of code for a file system. It also seems to me their goal is features first, everything else later. So that's your explanation for a poor stability record for a project like this.
ReiserFS does have better performance with large directories, which is its main advantage over other file systems. Metadata journaling was added relatively recently. It's not as scalable in other uses, such as large files, which XFS was designed to handle very well. Ext2/3 is the choice right now for servers because it's relatively more reliable and stable, and simpler than the other two. With ReiserFS you often stumble into incompatibilities with other things in the kernel, such as NFS and LVM. Also, if you use ReiserFS some software which expects traditional FS semantics may require patching.
On the other hand with traditional FSes, you may need to work around the "many files" problem by hashing.
MISC
We don't need bloated hardware and software to design fast portable computers which run circles around Transmeta in speed and power consumption. We don't need commonly used bloated embedded operating systems either (yes this includes embedded forms of Unix, too). We just use a different approach. It has been demonstrated to work very well, and perhaps even offend a few people :).
For all the reasons I've already stated.
It's certainly a great replacement for those people who 'just run Apache because'.
http://cr.yp.to/publicfile.html
So you're suggesting planning for needing the Apache features in the future? If that's not ridiculous, I don't know what is?
I basically said Apache is harder to secure, not insecure. Though its security record could have been better.
Smaller servers are easier to secure, that's my argument. Other servers actually have security as their goal, and easy and small configuration. I mentioned fnord in my other message. Similar easy to set up servers are publicfile and mini_thttpd.
Why bother disabling Apache's functionality, when you can save time and use something which doesn't require this, and is small in size and fast in speed in the first place?
Flexibility is important. However, flexibility does not equal unnecessary bloat. History has shown bloat leads to security problems and support overhead.
Why bother, when other servers are several times simpler to set up, smaller and faster? Pheh!
freshmeat.net is your friend. My favorite is fnord from http://fefe.de/fnord/
It's not flamebait. There are many alternative servers available whos primary goal is security. They're easier to configure, secure, and maintain. Besides, most people don't need all the bells and wistles Apache offers.
By running a web server that's easier to secure. Which is NOT Apache.