I can assure you that most people in the BSD-land don't buy a word from Theo without checking the facts first either. So outside OpenBSD you will find a lot of disagreement and not much desire to rant against him for the low gain it brings.
No, it doesn't. Some parts are even a lot worse: (a) hackers can now be considered as terroristic groups. (b) it is illegal to listen to electron emissions -- completely ignoring that it is the intention of many devices like WLAN (c) limits based on the intented use be found only in the addition comments from the subcommittee for laws, not in the actual law itself.
The irony of this comment is that the binary logarithm of 10k is still much smaller than 32. Radix sort is efficient for other reasons.
First it doesn't require the whole dataset to exist at a time. This is nice for things like bzip2 where the data itself is partly generated.
Second it has predictable memory access patterns. This makes it nice for any modern CPU and is the reason why for many applications merge sort is already faster than quick sort.
Well, at least for NetBSD it is a major issue to keep compatibility going back to NetBSD 0.9. That might not be the full 15 years, but given that the project is not that old, it is a damn good job. There are a few exceptions to the compatiblity rule, e.g. low-level interfaces to the process table etc., but that's something even Microsoft changed a number of times.
Try PgAccess. IMO much nicer than phpMyAdmin. It also speaks for itself, that even for easy stuff like adding a user, almost noone uses the mysql internal tools. Depending on the needs, it can be as simple as createdb + createuser in PostgreSQL, e.g. when using PAM or ident for authentication and one database per user.
Update your facts. There are exactly two areas where MySQL is noticable faster than PostgreSQL. Those are connection time and non-transactional queries. If you depend on the former -- rewrite your programs, they are bogus. If you depend on the second, pray that the load will not increase enough to kill your database either by inconsistencies or locking. As soon as it comes to complex queries, PostgreSQL runs circles around MySQL.
MySQL 5 is still lacking a lot, most importantly in the I of ACID. It does not ensure integrety, it does things behind the scene which do not match the SQL commands. Silently trunkating data is evil, just like creating invalid dates. No excuses, MySQL just sucks in that department. Besides, stuff like the query cache don't belong into the database server. They belong into the middleware, since that is exactly where the necessary context is.
Last but not least, I do consider PostgreSQL to be much easier to administrate. I have central authentication support, I don't need magic commands to update the internal state of the server etc. It just works.
The LAMP argument is useless. Neither is PHP often a good choice for good web programming, nor is Apache necessarily the best web server. Just because a lot of people ask for it, doesn't make it good. You know the most popular Operating System out there, don't you?
Sorry, but wrong. It doesn't matter whether you need a few more bytes per routing table entry. What matters is whether you can reduce the *number* of routing entries by a few factors. All the class-less routing in IPv4 has dramatically increased the number of routes for backend routers. Those areas matter and you can reduce the number of routes by using hierachical routing.
Just to give you an example, each carrier can start to assign IPv6 addresses regionally without problems (large namespace) without having to add global routes.
(1) Easy installation: I've been said that PC-BSD does exactly that. The BSD-installer is every easy to use, the rest (up to date software) can be fetched very easy in all BSDs. (2) NVidia support FreeBSD officically. ATI is a mess, but that doesn't differ much from Linux. (3) Mostly a question of money, so what? A lot of Oracle installations are not on Linux after all. (4) YOU WANT HYPERTHREADING? Come on, get real SMP. HT just sucks. (5) All BSDs have e.g. hot plugging in the kernel. Read: In the kernel, not some stupid userland dameon. (6 There's a lot of hardware for very specialised applications. Heck, there's a lot of stuff only DOS drivers exist for. Most common devices are supported by both, with some big weaknesses in the multimedia sector. (7) SELinux is a big hack. Compare that to FreeBSD's MAC framework (which supports the SELinux ruleset BTW), it's much cleaner. Like properly designed. (8) *hust* I know that some of the Journaling Filesystems were mature before ported to Linux, but that doesn't mean that they are as mature under Linux as under the original system. JFS is the best example. Talking about mature, did they fix the filesystem corruptions under Ext3 already?
Actually, once you start choosing your hardware for your OS, the driver support becomes mostly mood. You are not buying IA32 for zOS afterall.
I said you can get 30% in one run. Let's say you have 768bit RSA key, with 30% known you are in the area of keys which have been broken. Keep in mind that work needed to factorize a key is at the very least a polynom of degree 6, if it isn't exponential. Reducing the effective key size by 30% saves a lot of time.
Get the facts. Colin showed that you can retrieve ~30% of a RSA key by running a program in parallel. This can be improved most likely if you have the chance to do it more than once. It is also imported to keep in mind that you can't entirely avoid an unbalanced memory access pattern without also taking a huge performance penalty.
The point of this debatte is that the Intel implementation sucks, it allows you to spy a lot on processes running on the virtual CPU. Sure, there are better alternatives than disabling HTT like the suggestions of Colin to only schedule threads of the same program on the virtual CPU. Actually, that is something you want to do anyway or otherwise you can seriously loose speed and drop under the performance of a processor with HTT disabled.
Speaking of paranoia, it is often not a bad thing to have, many big security problems can be avoided. Oh, I forget to patch the Linux box next door.
Re:just when OpenBSD i386 started to move to 3.x
on
GCC 4.0.0 Released
·
· Score: 1
They might be able to produce an over simplified version of NTP with ease, but I think producing a full compiler suite with about one and a half developers is going to be a bit more than they can handle. Should be fun to watch though.
If any of the many persons complaining about OpenNTPD would have actually tried to improve it, it would already be much better. Actually, improving OpenNTPD to a level where the sync rate is smaller than the standard deviation of the NTP servers was not that much work.
Yes, I have heard of --posix. I also know that it does not work. It doesn't create POSIX-compliant archives and even the manpage admits it. This is something I call a bug. There are various situations which GNU tar fails to handle correctly either by failing or creating correct streams. The FSF way of testing GNU tar is testing that GNU tar does what GNU tar is supposed to do. Not tar, GNU tar. I don't call a tool stable, if it does fail to work correctly.
For the copyright issue, like most European nations, the German copyright is based on human rights, you can't sell it. You can share the copyright, you can give an exclusive license, but it is not possible to completely hand over all your rights. Beside, this is something I as a developer would never do.
It sounds like Stallman had a point. You don't go around rewriting things for the sake of it. Does gtar need constant development? No, it's in a stable state. As I recall, automated testing of the GNU toolset compared extremely well with other versions - you don't throw away that stability just because the code is ugly.
The whole point of Stallman was that Schily as German didn't want to hand over the copyright because he's legally not allowed so. Also GNU Tar is not stable. It is incompatible with almost any other tar on the world. Yeah, that's not a problem for the GNU guys, "Our tar is better, use it". Heck, the code is not only ugly, it is full of bugs.
DragonFly and FreeBSD come with fetch, which offers most of the functionality of wget (minus the mirror stuff). That's enough to download tarballs and the like. For packages, you can also directly use "pkg_add -r" to use binary packages e.g. from gobsd.com without having to compile them or even install the ports tree.
A browser doesn't belong into a base system, compare with Debian which also doesn't have one by default.
Having the bash as default shell is a typical Linux user comment. There are better shells which are smaller, faster or more comfortable without being GPL licensed.
It's better to specify i386-freebsd4.8 for configure, which is not a fault of DragonFly, but of configure.
DragonFly does currently have a small scheduler bug which leads to skips e.g. of MP3 during high disc activity. Other tasks e.g. the pipe handling are supposedly better than FreeBSD.
Yes, I'm sure. The mutex overhead with 512 CPU is even higher and our interrupt path (even for "slow" interrupts) is way faster than FreeBSD 5 or Linux. We are currently working on fully localizing interrupts in the system, just to avoid that.
That's plainly wrong. Most changes to the userland, e.g. the libc are available under the original license. Also various changes to kernel parts are kept under the original conditions.
It is true that the new code they wrote is distributed under Apple Public License, which isn't as free and short as the BSD license.
Message passing is used by micro-kernels, yes. There are other examples though. IIRC Solaris does have some primitives in its kernel. For the normal usage case, in-kernel message passing allows us to better separate work and simplifies development without all the overhead a micro-kernel involves.
Slashdot Mirror
I can assure you that most people in the BSD-land don't buy a word from Theo without checking the facts first either. So outside OpenBSD you will find a lot of disagreement and not much desire to rant against him for the low gain it brings.
No, it doesn't. Some parts are even a lot worse:
(a) hackers can now be considered as terroristic groups.
(b) it is illegal to listen to electron emissions -- completely ignoring that it is the intention of many devices like WLAN
(c) limits based on the intented use be found only in the addition comments from the subcommittee for laws, not in the actual law itself.
The irony of this comment is that the binary logarithm of 10k is still much smaller than 32. Radix sort is efficient for other reasons.
First it doesn't require the whole dataset to exist at a time. This is nice for things like bzip2 where the data itself is partly generated.
Second it has predictable memory access patterns. This makes it nice for any modern CPU and is the reason why for many applications merge sort is already faster than quick sort.
Well, at least for NetBSD it is a major issue to keep compatibility going back to NetBSD 0.9. That might not be the full 15 years, but given that the project is not that old, it is a damn good job. There are a few exceptions to the compatiblity rule, e.g. low-level interfaces to the process table etc., but that's something even Microsoft changed a number of times.
You know that the most energy consuming part of a CRT is the C? It is basically a light bulp and a good LCD is much more efficient than a bulp.
Sure, we are all just very busy writing abstracts and booking flights. No time to comment on /.
Oh, wait. Damn.
Try PgAccess. IMO much nicer than phpMyAdmin. It also speaks for itself, that even for easy stuff like adding a user, almost noone uses the mysql internal tools. Depending on the needs, it can be as simple as createdb + createuser in PostgreSQL, e.g. when using PAM or ident for authentication and one database per user.
Update your facts. There are exactly two areas where MySQL is noticable faster than PostgreSQL. Those are connection time and non-transactional queries. If you depend on the former -- rewrite your programs, they are bogus. If you depend on the second, pray that the load will not increase enough to kill your database either by inconsistencies or locking. As soon as it comes to complex queries, PostgreSQL runs circles around MySQL.
MySQL 5 is still lacking a lot, most importantly in the I of ACID. It does not ensure integrety, it does things behind the scene which do not match the SQL commands. Silently trunkating data is evil, just like creating invalid dates. No excuses, MySQL just sucks in that department. Besides, stuff like the query cache don't belong into the database server. They belong into the middleware, since that is exactly where the necessary context is.
Last but not least, I do consider PostgreSQL to be much easier to administrate. I have central authentication support, I don't need magic commands to update the internal state of the server etc. It just works.
The LAMP argument is useless. Neither is PHP often a good choice for good web programming, nor is Apache necessarily the best web server. Just because a lot of people ask for it, doesn't make it good. You know the most popular Operating System out there, don't you?
Sorry, but wrong. It doesn't matter whether you need a few more bytes per routing table entry. What matters is whether you can reduce the *number* of routing entries by a few factors. All the class-less routing in IPv4 has dramatically increased the number of routes for backend routers. Those areas matter and you can reduce the number of routes by using hierachical routing. Just to give you an example, each carrier can start to assign IPv6 addresses regionally without problems (large namespace) without having to add global routes.
(1) Easy installation: I've been said that PC-BSD does exactly that. The BSD-installer is every easy to use, the rest (up to date software) can be fetched very easy in all BSDs.
(2) NVidia support FreeBSD officically. ATI is a mess, but that doesn't differ much from Linux.
(3) Mostly a question of money, so what? A lot of Oracle installations are not on Linux after all.
(4) YOU WANT HYPERTHREADING? Come on, get real SMP. HT just sucks.
(5) All BSDs have e.g. hot plugging in the kernel. Read: In the kernel, not some stupid userland dameon.
(6 There's a lot of hardware for very specialised applications. Heck, there's a lot of stuff only DOS drivers exist for. Most common devices are supported by both, with some big weaknesses in the multimedia sector.
(7) SELinux is a big hack. Compare that to FreeBSD's MAC framework (which supports the SELinux ruleset BTW), it's much cleaner. Like properly designed.
(8) *hust* I know that some of the Journaling Filesystems were mature before ported to Linux, but that doesn't mean that they are as mature under Linux as under the original system. JFS is the best example. Talking about mature, did they fix the filesystem corruptions under Ext3 already?
Actually, once you start choosing your hardware for your OS, the driver support becomes mostly mood. You are not buying IA32 for zOS afterall.
I said you can get 30% in one run. Let's say you have 768bit RSA key, with 30% known you are in the area of keys which have been broken. Keep in mind that work needed to factorize a key is at the very least a polynom of degree 6, if it isn't exponential. Reducing the effective key size by 30% saves a lot of time.
The point of this debatte is that the Intel implementation sucks, it allows you to spy a lot on processes running on the virtual CPU. Sure, there are better alternatives than disabling HTT like the suggestions of Colin to only schedule threads of the same program on the virtual CPU. Actually, that is something you want to do anyway or otherwise you can seriously loose speed and drop under the performance of a processor with HTT disabled.
Speaking of paranoia, it is often not a bad thing to have, many big security problems can be avoided. Oh, I forget to patch the Linux box next door.
For the copyright issue, like most European nations, the German copyright is based on human rights, you can't sell it. You can share the copyright, you can give an exclusive license, but it is not possible to completely hand over all your rights. Beside, this is something I as a developer would never do.
The whole point of Stallman was that Schily as German didn't want to hand over the copyright because he's legally not allowed so. Also GNU Tar is not stable. It is incompatible with almost any other tar on the world. Yeah, that's not a problem for the GNU guys, "Our tar is better, use it". Heck, the code is not only ugly, it is full of bugs.
DragonFly and FreeBSD come with fetch, which offers most of the functionality of wget (minus the mirror stuff). That's enough to download tarballs and the like. For packages, you can also directly use "pkg_add -r" to use binary packages e.g. from gobsd.com without having to compile them or even install the ports tree.
A browser doesn't belong into a base system, compare with Debian which also doesn't have one by default.
Having the bash as default shell is a typical Linux user comment. There are better shells which are smaller, faster or more comfortable without being GPL licensed.
It's better to specify i386-freebsd4.8 for configure, which is not a fault of DragonFly, but of configure.
DragonFly does currently have a small scheduler bug which leads to skips e.g. of MP3 during high disc activity. Other tasks e.g. the pipe handling are supposedly better than FreeBSD.
Yes, I'm sure. The mutex overhead with 512 CPU is even higher and our interrupt path (even for "slow" interrupts) is way faster than FreeBSD 5 or Linux. We are currently working on fully localizing interrupts in the system, just to avoid that.
It is true that the new code they wrote is distributed under Apple Public License, which isn't as free and short as the BSD license.
Message passing is used by micro-kernels, yes. There are other examples though. IIRC Solaris does have some primitives in its kernel. For the normal usage case, in-kernel message passing allows us to better separate work and simplifies development without all the overhead a micro-kernel involves.