And yet... other languages with smaller APIs let you do all the same things, without more effort (often with less) with a smaller API. The Java API is bloated because the architects were in love with abstraction.
The Java API is so large that wheels often get reinvented because no one can bloody find the 19" wheel with a particular bolt pattern an the type of treads they want.
It might be slow but it's not slower than Python. Not even close. Yet, Python is cool. It's because Python is fun. Partisans of other languages will likely feel the same about their language, and they're probably correct, but I don't know many people that way about Java.
Or just do what I do. Put all the stuff you care about on another computer with a time tested filesystem, and share it over the network. NFS is fast and has low latency. Not nearly as fast as a local drive (although you still want gigabit with good Intel NICs, you'll blow right past 100 megabit speeds), true, but fast enough for the things that typically reside in home directories. If necessary, files that must be fast can be stored on the local drive and rsync'd to the server regularly.
Then, you can switch filesystems and even OSes at the drop of a hat. You can blow away your entire hard drive and be up and running again in 20 minutes. The things that really benefit from a fast drive stay local and fast. The things that should be safe and easy to access and maintain stay on a server running OpenBSD or Debian-stable or something.
Another advantage is switching OSes. Linux has poor UFS support and no UFS2 support. FreeBSD has poor ext2 support, and you wouldn't want a partition that's supposed to be safe running that anyway. The only other common FS is vfat, which isn't even an option. With NFS, you can read it from anywhere (even MacOS X and Windows).
The one thing to consider is getting a UPS for the server. Async NFS mounts are much faster, but more vulnerable to power dropouts.
All the major distro's were already using a forked kernel anyway.
They were all using an out of date kernel with patches applied selectively and backported from newer versions. This gets much harder as the two versions drift.
Thus, the incentive to stay reasonably up to date. However, vanilla kernels won't be time tested code anymore, as they are still the development branch. It's a lot more complicated than just accepting or rejecting patches, and distributions like Slackware don't have the resources to keep rolling their own kernels.
Distro's will still take linus' official kernel releases, and then modify them to fit their purposes.
Regression testing is very time consuming, and modifying something for stability takes a lot of it. This task is much more complicated than you seem to think.
On the other hand, nobody should ever have a need to do that.
You've never needed to install a vanilla kernel for any reason?
You can pick and choose the parts of Linux you want. (Check out Gentoo if you doubt this.)
Check out Gentoo, hey? I'll just do that right now.
$ uname -a Linux thecheat 2.6.8-gentoo-r1 #1 Wed Aug 18 13:43:15 MDT 2004 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
I was talking specifically about the Linux kernel. I stand by what I said. The kernel will be forked.
This is a really silly discussion. BusinessWeek has a column by an idiot who has no clue.
I agree about that. All arguments about merit aside, it simply would not be practical to get every author of kernel code to relicense their work. Therefore, Linux (the kernel) is GPLed for the forseeable future.
Switching to a BSD license will just encourage code forking which is bad.
As opposed to what, picking a development model that forces distributions to fork? 2.6 is the active development kernel, and distributions are now responsible for putting together a stable kernel.
This will cause more situations similar to what Red Hat has done with their heavily customized 2.4 kernel. Distributions will have their own heavily patched kernels that can no longer be easily migrated to the current vanilla versions. There are several distributions with the resources to do this by themselves, and the smaller ones will probably band together to do it as well. If that's not a fork, it's the closest thing to it and will probably lead to a fork in the future.
It's not the BSD license that encourages forks. There were (are) two factors:
-Commerical forks can get specs on hardware that open source ones can't. Since they can't give the code of the driver back to the community, they must fork.
-The BSDs (not the license, but the OSes) are designed as complete operating systems, with a userspace and a kernel in one package. This encourages forking because it's less modular than Linux.
It's not the licenses that do it, it's the unique position the BSDs are in. There are BSD licensed projects which do not fork, such as Python, which uses a license similar to BSD. By similar, I mean it explicitly says you can fork, keep the code secret, and sell the results. Python hasn't forked because there's no motivation for people to do it.
I think it's more likely that it's sudo that's the administrative process. It has privs because it gets them from the setuid bit, and then it conditionally delegates the privs.
I think su also counts as prior art. The data store is/etc/groups (must be in wheel) instead of/etc/sudoers, and the program that actually gets run is a shell, but I'm not sure how that makes it different.
The numbers of PowerPC embedded processors shipped every year dwarf the combined total numbers of desktop, workstation, and server CPUs shipped every year from every architechture.
I thought about this for a while... I think OTP encrypted messages aren't quite impervious.
1) We can examine the messages sizes and timings to develop heuristics that tell us with a high degree of certainty what type of message it is. In the case of something like me typing my password, it might even be possible to figure out what keys I press from the timings, and we can tell the length as well. This applies to all cryptography that doesn't inject garbage to screw up these methods, but it's worth noting that OTP is not immune automatically.
2) If the probability of any given bit in our key being 1 is 50%, then it would be possible to do stuff like look at the high bit and figure out with a high degree of certainty what sort of traffic it is, eg: binanries or plain text. Having an additional layer of encryption, or maybe compression would defeat that, I hope.
"I've lost all faith in reviews by some of these hardware sites lately - they seem to be getting paid by someone to make invalid conclusions (or none at all) from fairly conclusive data."
It does not. Also, it does not allow one to choose which applications are allowed to bind to specific incoming ports, they're either open or they're not. Apparently the Windows Firewall can do that, though I don't personally know that to be true.
I use and liked Tiny when I still used Windows. It controlled connections both in and out by application, and it kept MD5 digests of all the allowed programs so it would be detected if they were changed. It was probably my favorite. It's not free (beer) anymore unfortunatley.
"Amusingly enough those type of people that you describe, who change their minds like the wind, who are inexperienced, tend to be the ones that I've met who prefer languages like perl, python, etc."
From my perspective, if none of the distros can do it out of the box, it can't be done. If it requires me to figure out some local hack, it's passed the threshold where I'm willing to put in the effort. The kernel may not be at fault (sometimes it is), but my stuff still doesn't work.
I'm as far from a naive user as you can get without being a kernel hacker, and I still have these problems.
Anyway.
I think there's a lesson in this. That lesson is to never post on slashdot when you've just come home from a bar.
Slashdot Mirror
And yet... other languages with smaller APIs let you do all the same things, without more effort (often with less) with a smaller API. The Java API is bloated because the architects were in love with abstraction.
meh
The Java API is so large that wheels often get reinvented because no one can bloody find the 19" wheel with a particular bolt pattern an the type of treads they want.
It might be slow but it's not slower than Python. Not even close. Yet, Python is cool. It's because Python is fun. Partisans of other languages will likely feel the same about their language, and they're probably correct, but I don't know many people that way about Java.
Or just do what I do. Put all the stuff you care about on another computer with a time tested filesystem, and share it over the network. NFS is fast and has low latency. Not nearly as fast as a local drive (although you still want gigabit with good Intel NICs, you'll blow right past 100 megabit speeds), true, but fast enough for the things that typically reside in home directories. If necessary, files that must be fast can be stored on the local drive and rsync'd to the server regularly.
Then, you can switch filesystems and even OSes at the drop of a hat. You can blow away your entire hard drive and be up and running again in 20 minutes. The things that really benefit from a fast drive stay local and fast. The things that should be safe and easy to access and maintain stay on a server running OpenBSD or Debian-stable or something.
Another advantage is switching OSes. Linux has poor UFS support and no UFS2 support. FreeBSD has poor ext2 support, and you wouldn't want a partition that's supposed to be safe running that anyway. The only other common FS is vfat, which isn't even an option. With NFS, you can read it from anywhere (even MacOS X and Windows).
The one thing to consider is getting a UPS for the server. Async NFS mounts are much faster, but more vulnerable to power dropouts.
All the major distro's were already using a forked kernel anyway.
They were all using an out of date kernel with patches applied selectively and backported from newer versions. This gets much harder as the two versions drift.
Thus, the incentive to stay reasonably up to date. However, vanilla kernels won't be time tested code anymore, as they are still the development branch. It's a lot more complicated than just accepting or rejecting patches, and distributions like Slackware don't have the resources to keep rolling their own kernels.
Distro's will still take linus' official kernel releases, and then modify them to fit their purposes.
Regression testing is very time consuming, and modifying something for stability takes a lot of it. This task is much more complicated than you seem to think.
On the other hand, nobody should ever have a need to do that.
You've never needed to install a vanilla kernel for any reason?
I'm impressed.
You can pick and choose the parts of Linux you want. (Check out Gentoo if you doubt this.)
Check out Gentoo, hey? I'll just do that right now.
$ uname -a
Linux thecheat 2.6.8-gentoo-r1 #1 Wed Aug 18 13:43:15 MDT 2004 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
I was talking specifically about the Linux kernel. I stand by what I said. The kernel will be forked.
This is a really silly discussion. BusinessWeek has a column by an idiot who has no clue.
I agree about that. All arguments about merit aside, it simply would not be practical to get every author of kernel code to relicense their work. Therefore, Linux (the kernel) is GPLed for the forseeable future.
Having no up to date stable kernel will encourage forking. All distributions must now roll their own stable kernel if they want one.
Even though they all have to release the changes back, they're still going to be incompatible eventually.
And when the goal is for the product to be used in commercial applications, like Python, they're still wrong?
That's how they want their code to be used.
Switching to a BSD license will just encourage code forking which is bad.
As opposed to what, picking a development model that forces distributions to fork? 2.6 is the active development kernel, and distributions are now responsible for putting together a stable kernel.
This will cause more situations similar to what Red Hat has done with their heavily customized 2.4 kernel. Distributions will have their own heavily patched kernels that can no longer be easily migrated to the current vanilla versions. There are several distributions with the resources to do this by themselves, and the smaller ones will probably band together to do it as well. If that's not a fork, it's the closest thing to it and will probably lead to a fork in the future.
It's not the BSD license that encourages forks. There were (are) two factors:
-Commerical forks can get specs on hardware that open source ones can't. Since they can't give the code of the driver back to the community, they must fork.
-The BSDs (not the license, but the OSes) are designed as complete operating systems, with a userspace and a kernel in one package. This encourages forking because it's less modular than Linux.
It's not the licenses that do it, it's the unique position the BSDs are in. There are BSD licensed projects which do not fork, such as Python, which uses a license similar to BSD. By similar, I mean it explicitly says you can fork, keep the code secret, and sell the results. Python hasn't forked because there's no motivation for people to do it.
The problem with that is that muons are expensive to get, and the muons often end up stuck to the ash, so it's hard to recycle them.
I think it's more likely that it's sudo that's the administrative process. It has privs because it gets them from the setuid bit, and then it conditionally delegates the privs.
I think su also counts as prior art. The data store is /etc/groups (must be in wheel) instead of /etc/sudoers, and the program that actually gets run is a shell, but I'm not sure how that makes it different.
No, I doubt you have the permissions for that.
/dev/uspto
sudo rm -rf
I write oil-related software.
Oh, wait. We don't even have a non-english version.
"they are not used much"
The numbers of PowerPC embedded processors shipped every year dwarf the combined total numbers of desktop, workstation, and server CPUs shipped every year from every architechture.
I thought about this for a while... I think OTP encrypted messages aren't quite impervious.
1) We can examine the messages sizes and timings to develop heuristics that tell us with a high degree of certainty what type of message it is. In the case of something like me typing my password, it might even be possible to figure out what keys I press from the timings, and we can tell the length as well. This applies to all cryptography that doesn't inject garbage to screw up these methods, but it's worth noting that OTP is not immune automatically.
2) If the probability of any given bit in our key being 1 is 50%, then it would be possible to do stuff like look at the high bit and figure out with a high degree of certainty what sort of traffic it is, eg: binanries or plain text. Having an additional layer of encryption, or maybe compression would defeat that, I hope.
I have a friend at NYU. You pretty much have to keep yourself provably protected at all times.
I mean, they litterally plug in, said "fuck", unplugged, and they were already infected with something.
They want an iBook...
I'm going to have to stop reading the comments on /. if every other post includes the sentence "I'd hit it.".
"As a US & Canadian citizen"
I didn't think the US recognized dual citizenship...
"I've lost all faith in reviews by some of these hardware sites lately - they seem to be getting paid by someone to make invalid conclusions (or none at all) from fairly conclusive data."
:)
We still have Ars.
That is useful information. I'm sure it will help others, but it came a bit late for me I'm afraid. :)
I've since upgraded my firewall, and I no longer use Windows on any of my computers.
It does not. Also, it does not allow one to choose which applications are allowed to bind to specific incoming ports, they're either open or they're not. Apparently the Windows Firewall can do that, though I don't personally know that to be true.
I use and liked Tiny when I still used Windows. It controlled connections both in and out by application, and it kept MD5 digests of all the allowed programs so it would be detected if they were changed. It was probably my favorite. It's not free (beer) anymore unfortunatley.
"Amusingly enough those type of people that you describe, who change their minds like the wind, who are inexperienced, tend to be the ones that I've met who prefer languages like perl, python, etc."
Ouch, man. That hurts.
From my perspective, if none of the distros can do it out of the box, it can't be done. If it requires me to figure out some local hack, it's passed the threshold where I'm willing to put in the effort. The kernel may not be at fault (sometimes it is), but my stuff still doesn't work.
I'm as far from a naive user as you can get without being a kernel hacker, and I still have these problems.
Anyway.
I think there's a lesson in this. That lesson is to never post on slashdot when you've just come home from a bar.