Of course Erlang isn't a toy language, and also has a bytecode VM, distribution, built-in massive concurrency (instead of the bolted-on concurrency), and fault tolerance features with a much smaller footprint than Java VM.
Actually writing servers in functional languages is not a big deal, especially when the language has libraries already written, such as Erlang. In fact, servers is something Erlang was designed for.
Nintendo uses Lisp for game programming, maybe even Mario64.
I am not sure about right. Can you really put all your trust into the organizations controlling DNSSEC after the buy-in? If on the other hand, an alternative was available which wouldn't depend on such centralization, then we would have something to talk about.
DNSSEC is vaporware. AFAIK It was never finished, much less deployed by Verisign or anyone else. Quoting Vixie:
"We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?"... It's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. It sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. When will it be? We don't know. What has to happen before we will know? We don't know that either....
2535 is already dead and buried. There is no installed base. We're starting from scratch"
How about with modifying existing web browsers' dialog-boxes to make them less scary, and explain that an unknown root CA doesn't mean end of the world. Then a user could visit the free CA's site, decide if they can trust it, and add it to the configuration if desired.
Regardless whether it's a big known CA or not, people make mistakes, and a certificate signed by any CA still carries risk IMHO.
This is great, however, where's the internals documentation for other subsystems of the kernel? People need documentation for JFS, ReiserFS, and other large systems. We'd see more of these in other kernels.
http://wonka.acunia.com/. Also FreeBSD will soon get native Java. They're working on it. Also, it's possible to recompile JDK from source for *BSD. Yes, it is labor intensive.
Also compiling with the highest optimization level won't necessarily result in the best possible binary. Profiling is the only way to tell whether it contributed to performance over lower optimization options, or was a detriment.
-fomit-frame-pointer will save a register on x86, and generate smaller code. This has been perfectly safe for me, but if you need debugging, it will break it.
For floating point applications - sometimes optimizing for size (-Os) wins over other optimizations.
No. OSS is OSS. A linux distribution is the Linux kernel and other bundled OSS. Not all OSS can be used by anyone either - depends on the license.
OSS isn't developed especially for Linux. OSS is developed for any OS it targets (and usually almost any Unix as long as there are no portability problems).
There's more non-free software written for Linux and other free Unixes every year because there's demand. Easysoft OOB is available for Linux and FreeBSD among others, Opera is available as a native binary for FreeBSD or Linux. Oracle is available for Linux, Sybase is available for Linux. The list of important commercial software is quite long.
And of course, if it's available for Linux in a binary chances are it will run on any of the BSDs.
Free Unix other than Linux: FreeBSD, NetBSD, and OpenBSD developments such as built-in zero-copy in NetBSD, faster pipes, and verified exec. softupdates improvements in all three. The dirpref and dirhash FS improvements. Unified FS buffer cache and SMP in NetBSD-current.
And of course the OpenBSD project has been good with OpenSSH, except for the exploit and trojan problems they had in 2002 year.
There are ambiguities of what Linux and GNU/Linux actually mean. Some people refer to some distributions as "Linux". Other refer to them as "GNU/Linux", others prefer to call the Linux kernel "Linux". Most usually forget not all free software is written for it. Especially here.
KDE and GNOME are not Linux specific. cdrecord is not Linux specific. wine is not Linux specific AFAIK. Xine and Mplayer are not Linux specific. The year was good for Unix, not only Linux.
So the default Helvetica for everything approach works great for nerds?
Fonts are a big problem with X, and X applications. This is an area that definitely needs improvement. Another biggie is the lack of consistency among X applications such as cut and paste, look and feel, configuration, etc (but all this is tangentally related to Unix; these are X problems).
And why is this story relative to "GNU/Linux" only? Why not free Unix? Oh, I forgot, it's Slashdot. Mark this one flamebait.
You mean poll() and select() scalability issues? The best solution is then to fix poll() and select() to scale with large number of FDs. According to benchmarks done by Dan Kegel, at least Linux has this scalability problem.
Also see www.untroubled.org for twoftpd. Another FTP server with similar goals as vsftpd. Haven't had an overflow AFAIK. Also, could you point me to the sqwebmail buffer overflow please. Thanks.
It needs to happen some day. I think only those systems who would like to participate in the new infrastructure will switch first (once the software is written). Then, the number of users will grow. Similar to IPV6.
"Client filtering is an idea that's appealing only to people who don't really understand email technology, or who are acting willfully ignorant because they have a secondary agenda."
Unfortunatly other forms of filtering do not work as well as they should. Black lists are great for filtering the bulk of SPAM, but they're not perfect. What's a sysadmin to do? Use two types of filtering. Deny access from blacklisted sites, and tag the rest. There will be false positives, but at least an end-user will have an easier way to filter (by tag headers).
Slashdot Mirror
Of course Erlang isn't a toy language, and also has a bytecode VM, distribution, built-in massive concurrency (instead of the bolted-on concurrency), and fault tolerance features with a much smaller footprint than Java VM.
hello() -> io:fwrite("hello\n").
"io" is module, not file.
Actually writing servers in functional languages is not a big deal, especially when the language has libraries already written, such as Erlang. In fact, servers is something Erlang was designed for.
Nintendo uses Lisp for game programming, maybe even Mario64.
I am not sure about right. Can you really put all your trust into the organizations controlling DNSSEC after the buy-in? If on the other hand, an alternative was available which wouldn't depend on such centralization, then we would have something to talk about.
DNSSEC is vaporware. AFAIK It was never finished, much less deployed by Verisign or anyone else. Quoting Vixie:
... ...
"We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?"
It's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. It sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. When will it be? We don't know. What has to happen before we will know? We don't know that either.
2535 is already dead and buried. There is no installed base. We're starting from scratch"
How about with modifying existing web browsers' dialog-boxes to make them less scary, and explain that an unknown root CA doesn't mean end of the world. Then a user could visit the free CA's site, decide if they can trust it, and add it to the configuration if desired.
Regardless whether it's a big known CA or not, people make mistakes, and a certificate signed by any CA still carries risk IMHO.
This is great, however, where's the internals documentation for other subsystems of the kernel? People need documentation for JFS, ReiserFS, and other large systems. We'd see more of these in other kernels.
http://wonka.acunia.com/. Also FreeBSD will soon get native Java. They're working on it. Also, it's possible to recompile JDK from source for *BSD. Yes, it is labor intensive.
Also compiling with the highest optimization level won't necessarily result in the best possible binary. Profiling is the only way to tell whether it contributed to performance over lower optimization options, or was a detriment.
My understanding from what I've read from first person accounts is you judge yourself, God doesn't judge in the traditional Christianity sense.
www.near-death.com is the basis of my beliefs.
-fomit-frame-pointer will save a register on x86, and generate smaller code. This has been perfectly safe for me, but if you need debugging, it will break it.
For floating point applications - sometimes optimizing for size (-Os) wins over other optimizations.
Care to share where this solution is as far as XFree86 is concerned?
"Linux has OSS that can be used by anyone else."
No. OSS is OSS. A linux distribution is the Linux kernel and other bundled OSS. Not all OSS can be used by anyone either - depends on the license.
OSS isn't developed especially for Linux. OSS is developed for any OS it targets (and usually almost any Unix as long as there are no portability problems).
There's more non-free software written for Linux and other free Unixes every year because there's demand. Easysoft OOB is available for Linux and FreeBSD among others, Opera is available as a native binary for FreeBSD or Linux. Oracle is available for Linux, Sybase is available for Linux. The list of important commercial software is quite long.
And of course, if it's available for Linux in a binary chances are it will run on any of the BSDs.
Free Unix other than Linux:
FreeBSD, NetBSD, and OpenBSD developments such as built-in zero-copy in NetBSD, faster pipes, and verified exec. softupdates improvements in all three. The dirpref and dirhash FS improvements. Unified FS buffer cache and SMP in NetBSD-current.
And of course the OpenBSD project has been good with OpenSSH, except for the exploit and trojan problems they had in 2002 year.
Bill Gates gets it. MS is very busy at rectifying the situation.
There are ambiguities of what Linux and GNU/Linux actually mean. Some people refer to some distributions as "Linux". Other refer to them as "GNU/Linux", others prefer to call the Linux kernel "Linux". Most usually forget not all free software is written for it. Especially here.
Not everybody runs RedHat. This isn't an RH issue, it's the X issue.
KDE and GNOME are not Linux specific.
cdrecord is not Linux specific.
wine is not Linux specific AFAIK.
Xine and Mplayer are not Linux specific.
The year was good for Unix, not only Linux.
So the default Helvetica for everything approach works great for nerds?
Fonts are a big problem with X, and X applications. This is an area that definitely needs improvement. Another biggie is the lack of consistency among X applications such as cut and paste, look and feel, configuration, etc (but all this is tangentally related to Unix; these are X problems).
And why is this story relative to "GNU/Linux" only? Why not free Unix? Oh, I forgot, it's Slashdot. Mark this one flamebait.
And this gets a score of 2?. Moderators, YHBT!
You mean poll() and select() scalability issues? The best solution is then to fix poll() and select() to scale with large number of FDs. According to benchmarks done by Dan Kegel, at least Linux has this scalability problem.
Also see www.untroubled.org for twoftpd. Another FTP server with similar goals as vsftpd. Haven't had an overflow AFAIK. Also, could you point me to the sqwebmail buffer overflow please. Thanks.
It needs to happen some day. I think only those systems who would like to participate in the new infrastructure will switch first (once the software is written). Then, the number of users will grow. Similar to IPV6.
"Client filtering is an idea that's appealing only to people who don't really understand email technology, or who are acting willfully ignorant because they have a secondary agenda."
Unfortunatly other forms of filtering do not work as well as they should. Black lists are great for filtering the bulk of SPAM, but they're not perfect. What's a sysadmin to do? Use two types of filtering. Deny access from blacklisted sites, and tag the rest. There will be false positives, but at least an end-user will have an easier way to filter (by tag headers).
Read the link.