Oh yes it is. When I log in a user with bash as shell, you can _feel_ the delay while bash and the dynamic libraries of it are loaded. Yes, even on my Athlon XP. Why? Because my init system loads neither glibc nor bash.
KDE is only faster than 2.x if you disable all the new eye candy that is now available, like translucent menus and the flashy theme stuff. Yes, that's comparing apples and oranges, but it's also comparing the default desktops. Keramik is themed with large pixmaps, the kde 2.x default layout wasn't (or I'm on crack and didn't notice).
The standard Linux init system is based on sysvinit and is slow precisely _because_ it is interpreted (it's basically a ton of shell scripts). The other reason why it's so slow is because glibc is slow and the init system starts several hundred processes during the init process. Just log in on a freshly restarted Linux system and type "echo $$" in a shell prompt to see how many programs were run before you logged in. On my minit based notebook, the number is below 20. On my minit based server, it's still below 30.
minit takes less than one second to initialize the whole server system, on an aging 466 MHz Celeron box, right from the point where the kernel starts init up to the login prompt. And the server does file sharing, cvs serving, rsync serving, runs a mail server and sshd.
In fact, because minit does not even depend on glibc, minit can probably initialize a small system in less time than it takes to even load python and glibc on this init system.
Fast and python based, give me a break. And the freedesktop people should keep their bloat to themselves, if you ask me. With the notable exception of KDE, all the gui systems on Linux have gotten progressively slower and more bloated over the years. KDE has also become slower, but less drastically, so it can be excused IMHO. But Gtk? Give me a break! Even starting the gnome theme engine takes 5 seconds on my 2 GHz Athlon XP!
Intel has a history of cheating benchmarks and outright manipulation of "industry" benchmarks like Babco to make their products look good.
Most of the lead of their products in benchmarks these days come from either a) memory bandwidth (Athlon 64 has even more bandwidth than P4) or b) SSE2 (Athlon 64 also has SSE2).
Even if Prescott has x86-64 instructions, there is no reason to believe it will outperform an Athlon 64. In fact, current benchmarks indicate that Athlon 64 wipes the floor with everything Intel has to offer.
It is true that the Athlon 64 is expensive. The Pentium 4 is also very expensive. AMD is trying to make some money here, before again descending into price wars with Intel. As soon as Intel slashes prices, so will AMD.
I suggest reading the Inquirer regularly to read about Intel's Babco cheating details (the Pentium M Babco results make this very clear). I will not support cheats and sore losers like Intel with my money.
It's a tiny statically linked init that besides offering make-like dependencies to load services in parallel also offers ways to avoid spawning a thousand shell and utility processes in the boot process.
On my notebook, it takes less than a second from the start of init to a login prompt. In fact the latency is so small that I have never used the APM or ACPI suspend mode any more, I just turn the notebook off and on again. That's actually faster than the BIOS suspend-to-disk feature.
minit also has other benefits over standard init: you can ask init for the PID of services like sshd without PID files and thus even on read-only media like a CD-ROM without initial RAM disk or shmfs.
It's Linux only, though. And you need the diet libc for full effect (52k memory footprint for init on my desktop, including shared read-only pages).
I have not read your book, and I don't think I will.
How can you write a book about secure programming if you are obviously not even capable of understanding the difference between a language ("C") and a run-time environment ("libc", sprintf and strcpy and friends).
C and C++ are not insecure at all. C does not force anyone to use C strings and functions using format strings. If you do, and you don't know what you are doing, you will probably create buggy and insecure code. That's not C's fault. If you don't know what you are doing, you shouldn't be doing brain surgery or repairs on the space shuttle either.
I'm appalled at the flood of bad security and crypto books lately. Having the few good books diluted by a torrent of bad books is worse than having no books on the topic at all. Frankly, your review of Applied Cryptography speaks volumes. I'm not interested in security advice from people who complain about "all those difficult math symbols". Now please go back to Visual Basic, thank you very much.
The US "free market" speech is cynicism of the highest order, which is abundantly clear with the US farm goods, which are highly subsidized by the government. Then the USA is using "free market" treaties to force the poor Mexicans (whose government can not afford these subsidies) to buy the "cheaper" US farm goods instead of their own, which are actually produced at substantially lower prices.
All the potentially noble thoughts behind this free market newspeak is completely eviscerated by the subsidies of the various governments. As long as governments subsidize their local producers, there is nothing free about the market.
Is having a kitchen an impediment to the free market of restaurants?
Is driving a car an impediment to the free market of taxi and train companies?
Get real, man.
Free market means that people have the freedom to choose which product to use, and these countries choose to make and use their own. There is nothing wrong with that, not even considering the "free market" globalization iron fist of driving poor countries into complete bankruptcy (read the book and articles from Greg Palast for scary documentation about this).
In fact, it is in their best interest to reduce their dependency on software imports from other countries, and everyone acting in their own best interest is exactly the idea of free markets.
First of all, the CA has a business interest in selling as many certificates as possible, so it does not make sense to assume it will exert due diligence to find out whether someone is a spammer.
Second of all, spammers won't go to the CA and make it obvious they are spammers. They will pose as flower delivery agents with a brand new name, and the CA will give them a certificate and that's it. Then the spammer will start spamming, someone will complain to the CA, and they will issue a revocation certificate. In case you don't know TLS very well: revocation certificates do not scale AT ALL, it basically means that the AMTP server needs to have all on disk or we need a protocol to get them (possibly LDAP?). Since spammers will be using throw away identities just like they do now, I am seeing millions of revoked certificates.
So the only thing this approach does is create an artificial bottleneck at the CA, because they will be responsible for revoking the spamming "rights". Spammers will still spam and then in response be denied access, just like now, so even if this CA stuff works perfectly, and we have a high performance revocation certificate request protocol (which by the way entails enormous bandwidth cost for the CA, if all the mail servers in the world send a query for each incoming email, think about it!), we will still have exactly the same amount of spam we have now, because spammers will still spam first and be denied access later.
The next question is: what do we do about non-responsive CAs? Let's say Verisign gets in the email CA business, and they basically run the same fully automated CA business they do now, and they get bribed by the spammers just like ISPs get bribed by them now, and they don't revoke the certificate of a spammer, what are you going to do? Not accept any mail from anyone signed by Verisign ever again? That is basically your only option, and it is even worse than the collateral damage we have these days, when "only" one IP is barred (not counting SPEWS). If you think bribing Verisign is unlikely, consider the stakes! If you successfully bribe Verisign as spammer, you basically have permission to spam everyone, all over the world, and nobody can do anything about it except what we do now, unsuccessfully, i.e. block single IPs. And the spammers are still in business, so it's not enough.
So all in all, I think this is a spectacularly bad idea that will not work on ANY level. The up side is that it may finally bring encrypted email to everyone.
Am I the only one who finds it hypocritical to talk about anonymizing, freedom and free surfing and then filter porn away?
Or that they are planning to spam the citizen of Iran to get them to know the URL, when spam is outlawed in wide parts of the USA because people hate being spammed?
If the "freedom" we want them to have consists of being able to watch the Voice of America (which is operated openly as propaganda channel of the US government), it's not really real freedom, is it?
I'm not saying we need to use tax money to deliver porn to Iraq, but it is a vital part of our Western culture. We can't just pretend it's not there when we try to tell Iran how great our culture is (and that is exactly what Voice of America does).
Why? Because it means people will spend money on infrastructure, which increases cash flow in the IT industry, which will help keep the bubble afloat a while longer.
A lot of the growth of the computing industry comes from making smarter and backwards compatible products. But look what it got Microsoft to make an Office version that is backwards compatible -- they had to use various other means to ram it down people's throats, because they didn't feel they needed to new version.
A large part of the turnover and the jobs in the computing industry come from people buying stuff anew they already have, because the new version won't play with the old version.
This will probably not be so important an argument for the US economy any more, since those jobs are now in India and China, but this cycle of renewal is what secured the survival and even growth of the industry until now.
First of all, it's just a small wrapper library that is comparatively easy to reverse engineer.
Second of all, there is a library we can reverse engineer.
Third of all, the guy is using the VIA forums to spread the word, so VIA obviously knows about this, and they haven't sued.
To me this rather looks like they were waiting for someone to reverse engineer this, because they couldn't release the sources themselves for contractual reasons. Don't just assume people are evil, maybe they didn't have a choice and did what was in their power to give you the means to help yourself.
And Japan probably would even have the funds - they have the second largest military expenses in the world, after the USA. If they cut back on all that useless military crap (at least the USA uses their army to liberate oil, uh, countries, the Japanese army just sits there), they could pay for something like this, and I think it would be a huge catalyst for science and technology.
Catalysts like this are always a good idea, just look at how the Earth Simulator is already being used by big Japanese conglomerates.
By the way: I would really like to know why the Japanese didn't start exploiting the cheap Chinese labor before the western nations. They are much closer, after all. Why is it that they rather go into a 20 year recession than exploit Chinese? Are they more ethical or moral than us?
Yeah, right, it will help cure cancer! And AIDS! And... wait, what other scare words do we have... SARS, yeah, that's it! Oh, and it will also grow back hairs and enlarge your penis, while we are at it. Did I mention that it will help you stay young?
All of these claims are completely unproven, and man has a track record of blowing stuff up when given the opportunity. Military people are already talking about bioweapons engineered to only kill one person or maybe a certain ethnic group. These monstrosities maybe don't look like Godzilla, but they are reality, unfortunately.
Even worse, as long as parts of the genome can be patented, this is all a huge money grab that has absolutely nothing whatsoever to do with saving mankind of helping humanity.
Sheesh!
BTW: The pharmaceutical industry is interested in selling pills. Don't expect them to give you a genetic treatment that will actually cure you, there's no money in that. Expect them to use new technology to make more drugs that keep you alive enough to pay but sick enough to need more of them.
So he took a walk around the exhibition area and saw lots of companies. Yes, the exhibition area was surprisingly well populated, but the real meat of the event were the talks (ok, well, maybe I'm biased here because I held one of them).
By the way, there was at least one other party, from the local Linux User Group, on the second day. I couldn't attend because I was too sleepy.
The major highlight in my eyes were the GNOME and KDE talks. The GNOME talk was absolutely hilarious, mostly because the demonstrations crashed all the time. There were at least four spontaneously crashing applications in the presentation, the presenter did not even start two things he wanted to show because "they are broken right now" and the multimedia streaming framework "does not compile right now in CVS". So if you ever tried to compile GNOME from the sources: it's not your fault. In comparison, KDE looked like a finished and polished product, although the guy was also using the CVS version and had one problem where one application misbehaved so he restarted it. Anyway, this is a breeze of fresh air in the usual climate of corporate demos where they only show the stuff they know to work reliably. The Linux and Open Source people just proved that they don't do this to bullshit people, they do it for the fun of it!
By the way: the KDE and GNOME guys used the event to drink some beer together, and they are planning a soccer game (the Debian guys want to be the third team so it can be a tournament). All the talk about animosities is apparently completely unfounded.
BTW: the entrance fee to LinuxTag was free if you placed a reservation on their web page, and 10 Euros otherwise. So everyone and their kid brother were there, all the talks were packed with people. It was quite an impressive sight. I did the scalable network programming talk, which is a topic that normally wouldn't attract a large audience, and even that talk had over 200 attendees. I found the whole athmosphere there very nice and look forward to the next LinuxTag.
Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.
Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.
The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.
Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.
My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.
By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.
The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
IPv6 is bad because Cisco routers suck. No, wait, "Many of Cisco's routers" suck. You can' be serious! Once IPv6 gets off the ground, IPv6 will become fast path and eventually IPv4 will be dropped to legacy mode.
About your point 2: IPv6 does not actually give out all those 2^128 IPs. The first half is for the network part, the second 64 bits are for the host part. This is necessary because autoconfiguration (which is really great, by the way!) uses a 64-bit part. The IPv6 autoconfiguration is stateless, by the way, which means it will also work without a DHCP server and it won't need reboot if the routers were down when the autoconfiguration process started.
The point about having this many addresses is that you never ever want to have to come into the remote possibility to have to switch to IPv8 because IPv6 is too small. And when you rant about the IPv6 header being 20 bytes larger than the IPv4 header, consider that the overhead of the TCP header (20+ bytes), the HTTP header (300 bytes), the Email header (500 bytes?),... most of the internet protocols are very wasteful. On the other hand, they are easily debuggable with relatively simple tools. This is a trade-off, obviously, and IPv6's choice is not per se good or bad, it's just different. We will see whether it will have a significant overhead. I say getting rid of spam is a better way to reduce bandwidth requirements on the internet than talking about header sizes.
IPv6 is ready for prime time. People are using it (I, for example). You can buy access to IPv6-native backbones. All the major OSses support it. There is really no excuse not to be already using it.
The labels give the music to the radios but bill the artists for it. The artists also foot the bill for the rest of the promotion stuff, like ads in magazines.
This is part of the reason why only a handful of the very successful artists actually make money.
The labels are a sort of specialized bank, giving a lot of money to artists (well, not actually giving it to the artists, but spending it on behalf of the artists, and then billing the artists for it).
Try running Linux 2.5 on an nForce. What, no network driver? Well, who needs one of those these days, right? Or even try running *BSD!
I own an nvidia graphics card and am happy with it because some lunatics ported the nvidia driver to the 2.5 kernels. But the nforce users are pretty much lost.
Intel chipsets tend to be well supported as well, but let me mention these: "Winmodem" and "Centrino Wiress LAN". Good luck running OpenBSD on one of those. Apart from that, Intel chipsets are expensive and historically never performed well, especially on notebooks.
If I had to buy a new computer tomorrow, I would only even consider VIA and SiS. Both chipset companies are usually well supported by Linux and BSD, and their hardware is supported as soon as it is on the market. With Intel, you usually have to wait a few years until the hardware is obsolete and then Intel will release some driver under some non-GPL license (see the e100 driver for Linux, which was only recently released as GPL).
VIA and SiS may not be the highest performance chipsets around, but they work well, have absolutely no stability issues (except maybe under Windows) and are well supported. And "well supported" outweighs anything else anyway. I'm too old to run around in circles around nvidia or Intel, begging for even a binary only driver to get my machine to work at all.
Via is not as anal as Intel about their specs. Linux already has working support for the random number generator (their crypto extension), CPU frequency scaling (their SpeedStep/PowerNow equivalent), you aren't stuck with some proprietary and unsupported Intel wireless chipset, their USB, Firewire, Ethernet and IDE chips are proven technology and well supported by Linux,...
and I'm told there is even support for their hardware MPEG-2 decoder now in mplayer (haven't actually tried it yet). All in all this is some sweet hardware, and I'd much rather buy Via than Intel chipsets. With Intel chipsets, if something is unsupported, you are basically on your own. In contrast, Via has actually come forward on the mplayer mailing list and asked for people willing to help add support for their MPEG-2 decoder extension. What else could you possible ask for?
Personally, I don't care about 10% chipset performance as long as I know Linux works on the damn thing. Just google for the troubles people are having running Linux on their Centrino notebooks and you will see what I mean.
By the way: I can play full-screen DVD and DivX even on my (older and supposedly much inferior) 933 MHz Ezra C3, with AC3 sound. It's just a question of the correct compiler switches. These CPUs are not as fast as an Athlon or a Pentium M, and I wouldn't want to transcode a DVD to MPEG-4 on them, but they are fast enough to do real work like software development. If these become available in Germany, I'll buy one.
Can I see some numbers, please
on
Working Hard?
·
· Score: 1
Everyone likes to believe he is more productive than the rest of the world. I don't buy it. The facts are that the USA is importing much more than it is exporting, and this only works because the Dollar is the dominating currency and the US government can simply print more of them.
This is by the way a much more serious threat than WMD to the USA: that the Arab nations are considering switching to Euro. IIRC Iraq already did and Iran was thinking about it (or did they switch as well? Don't remember). Once the important economies switch to Euros, the Dollar will deflate very rapidly. Since practically nothing is actually produced in the USA anymore, there is nothing (apart from war) that the US government could actually be threatening anyone with. And once people don't depend on the Dollar, there is no reason to listen to the US government anymore.
THAT, my friend, is the real problem of the USA now. How did you believe the USA can survive pushing that giant debt around? The answer is: they can't, unless people don't care about their debt because they need more dollars for the international money exchange.
And apart from that: my personal statistics indicate that US IT workers are much less productive than others. You can measure it particularly well in the free software world. I suggest you take some time off (hehe) and do some statistics on Sourceforge mailing lists.
Re:Management doesn't get overtime anyway...
on
Working Hard?
·
· Score: 2, Insightful
The smart boss will fire you and keep the normal guy who works 9 to 5. Why? Because he knows that you will break down eventually.
It's not in the best interest of a project manager to have his workers break down of exhaustion a few days before the deadline. In fact, if the project manager hires someone like you at all, it would be with great unease and you probably won't get the really important assignments, because you can't be trusted to survive this self-exploitation indefinitely. From the perspective of the business owner (I am one), I have more than enough troubles to worry about. Having my employees break down in the midst of an important assignment is not one of them.
Excessive hacker types like that are great for hacker parties and open source projects, where it does not matter in the real life. But in the end you burn out and I have never seen anyone who could keep his productivity up all the time. These people stend to stay in the company just as long (or some even stay progressively longer) but get less and less work done, because they are constantly fatigued.
Trust me, it's better for you, for the company, for your family AND for your boss if you just work normal hours. Competent project managers will actually prefer it if you spend less time at work as long as you get your stuff done. Dependability is more important than "I'll show 'em" self annihilation.
I said the name was chosen to capitalize on the name of BIND, which is other people's work, basically.
All I'm saying is: you could have named it "vixdnsd" if you wanted people to use it on its own merits, not because they think they finally get a BIND version without all the pesky security problems.
It's the same as writing a web browser and calling it "Internet Explorer 7"; aside from trademark and copyright issues that's downright rude and a cheap way to capitalize on other people's work.
Slashdot Mirror
My desktop environment is fvwm and rxvt. I installed KDE 3.1.4 and 3.2 alpha and GNOME 2.4 to know what I'm ranting about.
Now that that's out of the way, I invite you to read this PDF to learn why I say that glibc is slow.
Oh yes it is. When I log in a user with bash as shell, you can _feel_ the delay while bash and the dynamic libraries of it are loaded. Yes, even on my Athlon XP. Why? Because my init system loads neither glibc nor bash.
KDE is only faster than 2.x if you disable all the new eye candy that is now available, like translucent menus and the flashy theme stuff. Yes, that's comparing apples and oranges, but it's also comparing the default desktops. Keramik is themed with large pixmaps, the kde 2.x default layout wasn't (or I'm on crack and didn't notice).
It's "faster", because it's "python based"?!
The standard Linux init system is based on sysvinit and is slow precisely _because_ it is interpreted (it's basically a ton of shell scripts). The other reason why it's so slow is because glibc is slow and the init system starts several hundred processes during the init process. Just log in on a freshly restarted Linux system and type "echo $$" in a shell prompt to see how many programs were run before you logged in. On my minit based notebook, the number is below 20. On my minit based server, it's still below 30.
minit takes less than one second to initialize the whole server system, on an aging 466 MHz Celeron box, right from the point where the kernel starts init up to the login prompt. And the server does file sharing, cvs serving, rsync serving, runs a mail server and sshd.
In fact, because minit does not even depend on glibc, minit can probably initialize a small system in less time than it takes to even load python and glibc on this init system.
Fast and python based, give me a break. And the freedesktop people should keep their bloat to themselves, if you ask me. With the notable exception of KDE, all the gui systems on Linux have gotten progressively slower and more bloated over the years. KDE has also become slower, but less drastically, so it can be excused IMHO. But Gtk? Give me a break! Even starting the gnome theme engine takes 5 seconds on my 2 GHz Athlon XP!
Intel has a history of cheating benchmarks and outright manipulation of "industry" benchmarks like Babco to make their products look good.
Most of the lead of their products in benchmarks these days come from either a) memory bandwidth (Athlon 64 has even more bandwidth than P4) or b) SSE2 (Athlon 64 also has SSE2).
Even if Prescott has x86-64 instructions, there is no reason to believe it will outperform an Athlon 64. In fact, current benchmarks indicate that Athlon 64 wipes the floor with everything Intel has to offer.
It is true that the Athlon 64 is expensive. The Pentium 4 is also very expensive. AMD is trying to make some money here, before again descending into price wars with Intel. As soon as Intel slashes prices, so will AMD.
I suggest reading the Inquirer regularly to read about Intel's Babco cheating details (the Pentium M Babco results make this very clear). I will not support cheats and sore losers like Intel with my money.
Adabas is now known as SAP DB, and you can download it at www.sapdb.org.
It's GPL. If Sun wanted, they could certainly ship it with OpenOffice.
See www.fefe.de/minit/ for info about the project.
It's a tiny statically linked init that besides offering make-like dependencies to load services in parallel also offers ways to avoid spawning a thousand shell and utility processes in the boot process.
On my notebook, it takes less than a second from the start of init to a login prompt. In fact the latency is so small that I have never used the APM or ACPI suspend mode any more, I just turn the notebook off and on again. That's actually faster than the BIOS suspend-to-disk feature.
minit also has other benefits over standard init: you can ask init for the PID of services like sshd without PID files and thus even on read-only media like a CD-ROM without initial RAM disk or shmfs.
It's Linux only, though. And you need the diet libc for full effect (52k memory footprint for init on my desktop, including shared read-only pages).
I have not read your book, and I don't think I will.
How can you write a book about secure programming if you are obviously not even capable of understanding the difference between a language ("C") and a run-time environment ("libc", sprintf and strcpy and friends).
C and C++ are not insecure at all. C does not force anyone to use C strings and functions using format strings. If you do, and you don't know what you are doing, you will probably create buggy and insecure code. That's not C's fault. If you don't know what you are doing, you shouldn't be doing brain surgery or repairs on the space shuttle either.
I'm appalled at the flood of bad security and crypto books lately. Having the few good books diluted by a torrent of bad books is worse than having no books on the topic at all. Frankly, your review of Applied Cryptography speaks volumes. I'm not interested in security advice from people who complain about "all those difficult math symbols". Now please go back to Visual Basic, thank you very much.
The US "free market" speech is cynicism of the highest order, which is abundantly clear with the US farm goods, which are highly subsidized by the government. Then the USA is using "free market" treaties to force the poor Mexicans (whose government can not afford these subsidies) to buy the "cheaper" US farm goods instead of their own, which are actually produced at substantially lower prices.
All the potentially noble thoughts behind this free market newspeak is completely eviscerated by the subsidies of the various governments. As long as governments subsidize their local producers, there is nothing free about the market.
Is having a kitchen an impediment to the free market of restaurants?
Is driving a car an impediment to the free market of taxi and train companies?
Get real, man.
Free market means that people have the freedom to choose which product to use, and these countries choose to make and use their own. There is nothing wrong with that, not even considering the "free market" globalization iron fist of driving poor countries into complete bankruptcy (read the book and articles from Greg Palast for scary documentation about this).
In fact, it is in their best interest to reduce their dependency on software imports from other countries, and everyone acting in their own best interest is exactly the idea of free markets.
First of all, the CA has a business interest in selling as many certificates as possible, so it does not make sense to assume it will exert due diligence to find out whether someone is a spammer.
Second of all, spammers won't go to the CA and make it obvious they are spammers. They will pose as flower delivery agents with a brand new name, and the CA will give them a certificate and that's it. Then the spammer will start spamming, someone will complain to the CA, and they will issue a revocation certificate. In case you don't know TLS very well: revocation certificates do not scale AT ALL, it basically means that the AMTP server needs to have all on disk or we need a protocol to get them (possibly LDAP?). Since spammers will be using throw away identities just like they do now, I am seeing millions of revoked certificates.
So the only thing this approach does is create an artificial bottleneck at the CA, because they will be responsible for revoking the spamming "rights". Spammers will still spam and then in response be denied access, just like now, so even if this CA stuff works perfectly, and we have a high performance revocation certificate request protocol (which by the way entails enormous bandwidth cost for the CA, if all the mail servers in the world send a query for each incoming email, think about it!), we will still have exactly the same amount of spam we have now, because spammers will still spam first and be denied access later.
The next question is: what do we do about non-responsive CAs? Let's say Verisign gets in the email CA business, and they basically run the same fully automated CA business they do now, and they get bribed by the spammers just like ISPs get bribed by them now, and they don't revoke the certificate of a spammer, what are you going to do? Not accept any mail from anyone signed by Verisign ever again? That is basically your only option, and it is even worse than the collateral damage we have these days, when "only" one IP is barred (not counting SPEWS). If you think bribing Verisign is unlikely, consider the stakes! If you successfully bribe Verisign as spammer, you basically have permission to spam everyone, all over the world, and nobody can do anything about it except what we do now, unsuccessfully, i.e. block single IPs. And the spammers are still in business, so it's not enough.
So all in all, I think this is a spectacularly bad idea that will not work on ANY level. The up side is that it may finally bring encrypted email to everyone.
Am I the only one who finds it hypocritical to talk about anonymizing, freedom and free surfing and then filter porn away?
Or that they are planning to spam the citizen of Iran to get them to know the URL, when spam is outlawed in wide parts of the USA because people hate being spammed?
If the "freedom" we want them to have consists of being able to watch the Voice of America (which is operated openly as propaganda channel of the US government), it's not really real freedom, is it?
I'm not saying we need to use tax money to deliver porn to Iraq, but it is a vital part of our Western culture. We can't just pretend it's not there when we try to tell Iran how great our culture is (and that is exactly what Voice of America does).
Why? Because it means people will spend money on infrastructure, which increases cash flow in the IT industry, which will help keep the bubble afloat a while longer.
A lot of the growth of the computing industry comes from making smarter and backwards compatible products. But look what it got Microsoft to make an Office version that is backwards compatible -- they had to use various other means to ram it down people's throats, because they didn't feel they needed to new version.
A large part of the turnover and the jobs in the computing industry come from people buying stuff anew they already have, because the new version won't play with the old version.
This will probably not be so important an argument for the US economy any more, since those jobs are now in India and China, but this cycle of renewal is what secured the survival and even growth of the industry until now.
First of all, it's just a small wrapper library that is comparatively easy to reverse engineer.
Second of all, there is a library we can reverse engineer.
Third of all, the guy is using the VIA forums to spread the word, so VIA obviously knows about this, and they haven't sued.
To me this rather looks like they were waiting for someone to reverse engineer this, because they couldn't release the sources themselves for contractual reasons. Don't just assume people are evil, maybe they didn't have a choice and did what was in their power to give you the means to help yourself.
And Japan probably would even have the funds - they have the second largest military expenses in the world, after the USA. If they cut back on all that useless military crap (at least the USA uses their army to liberate oil, uh, countries, the Japanese army just sits there), they could pay for something like this, and I think it would be a huge catalyst for science and technology.
Catalysts like this are always a good idea, just look at how the Earth Simulator is already being used by big Japanese conglomerates.
By the way: I would really like to know why the Japanese didn't start exploiting the cheap Chinese labor before the western nations. They are much closer, after all. Why is it that they rather go into a 20 year recession than exploit Chinese? Are they more ethical or moral than us?
Yeah, right, it will help cure cancer! And AIDS! And... wait, what other scare words do we have... SARS, yeah, that's it! Oh, and it will also grow back hairs and enlarge your penis, while we are at it. Did I mention that it will help you stay young?
All of these claims are completely unproven, and man has a track record of blowing stuff up when given the opportunity. Military people are already talking about bioweapons engineered to only kill one person or maybe a certain ethnic group. These monstrosities maybe don't look like Godzilla, but they are reality, unfortunately.
Even worse, as long as parts of the genome can be patented, this is all a huge money grab that has absolutely nothing whatsoever to do with saving mankind of helping humanity.
Sheesh!
BTW: The pharmaceutical industry is interested in selling pills. Don't expect them to give you a genetic treatment that will actually cure you, there's no money in that. Expect them to use new technology to make more drugs that keep you alive enough to pay but sick enough to need more of them.
Yes, but it's in German: http://www.fefe.de/linuxtag2003/
So he took a walk around the exhibition area and saw lots of companies. Yes, the exhibition area was surprisingly well populated, but the real meat of the event were the talks (ok, well, maybe I'm biased here because I held one of them).
By the way, there was at least one other party, from the local Linux User Group, on the second day. I couldn't attend because I was too sleepy.
The major highlight in my eyes were the GNOME and KDE talks. The GNOME talk was absolutely hilarious, mostly because the demonstrations crashed all the time. There were at least four spontaneously crashing applications in the presentation, the presenter did not even start two things he wanted to show because "they are broken right now" and the multimedia streaming framework "does not compile right now in CVS". So if you ever tried to compile GNOME from the sources: it's not your fault. In comparison, KDE looked like a finished and polished product, although the guy was also using the CVS version and had one problem where one application misbehaved so he restarted it. Anyway, this is a breeze of fresh air in the usual climate of corporate demos where they only show the stuff they know to work reliably. The Linux and Open Source people just proved that they don't do this to bullshit people, they do it for the fun of it!
By the way: the KDE and GNOME guys used the event to drink some beer together, and they are planning a soccer game (the Debian guys want to be the third team so it can be a tournament). All the talk about animosities is apparently completely unfounded.
BTW: the entrance fee to LinuxTag was free if you placed a reservation on their web page, and 10 Euros otherwise. So everyone and their kid brother were there, all the talks were packed with people. It was quite an impressive sight. I did the scalable network programming talk, which is a topic that normally wouldn't attract a large audience, and even that talk had over 200 attendees. I found the whole athmosphere there very nice and look forward to the next LinuxTag.
I attended Hans' presentation at Linuxtag.
Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.
Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.
The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.
Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.
My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.
By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.
The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
IPv6 is bad because Cisco routers suck. No, wait, "Many of Cisco's routers" suck. You can' be serious! Once IPv6 gets off the ground, IPv6 will become fast path and eventually IPv4 will be dropped to legacy mode.
... most of the internet protocols are very wasteful. On the other hand, they are easily debuggable with relatively simple tools. This is a trade-off, obviously, and IPv6's choice is not per se good or bad, it's just different. We will see whether it will have a significant overhead. I say getting rid of spam is a better way to reduce bandwidth requirements on the internet than talking about header sizes.
About your point 2: IPv6 does not actually give out all those 2^128 IPs. The first half is for the network part, the second 64 bits are for the host part. This is necessary because autoconfiguration (which is really great, by the way!) uses a 64-bit part. The IPv6 autoconfiguration is stateless, by the way, which means it will also work without a DHCP server and it won't need reboot if the routers were down when the autoconfiguration process started.
The point about having this many addresses is that you never ever want to have to come into the remote possibility to have to switch to IPv8 because IPv6 is too small. And when you rant about the IPv6 header being 20 bytes larger than the IPv4 header, consider that the overhead of the TCP header (20+ bytes), the HTTP header (300 bytes), the Email header (500 bytes?),
IPv6 is ready for prime time. People are using it (I, for example). You can buy access to IPv6-native backbones. All the major OSses support it. There is really no excuse not to be already using it.
The labels give the music to the radios but bill the artists for it. The artists also foot the bill for the rest of the promotion stuff, like ads in magazines.
This is part of the reason why only a handful of the very successful artists actually make money.
The labels are a sort of specialized bank, giving a lot of money to artists (well, not actually giving it to the artists, but spending it on behalf of the artists, and then billing the artists for it).
Try running Linux 2.5 on an nForce. What, no network driver? Well, who needs one of those these days, right? Or even try running *BSD!
I own an nvidia graphics card and am happy with it because some lunatics ported the nvidia driver to the 2.5 kernels. But the nforce users are pretty much lost.
Intel chipsets tend to be well supported as well, but let me mention these: "Winmodem" and "Centrino Wiress LAN". Good luck running OpenBSD on one of those. Apart from that, Intel chipsets are expensive and historically never performed well, especially on notebooks.
If I had to buy a new computer tomorrow, I would only even consider VIA and SiS. Both chipset companies are usually well supported by Linux and BSD, and their hardware is supported as soon as it is on the market. With Intel, you usually have to wait a few years until the hardware is obsolete and then Intel will release some driver under some non-GPL license (see the e100 driver for Linux, which was only recently released as GPL).
VIA and SiS may not be the highest performance chipsets around, but they work well, have absolutely no stability issues (except maybe under Windows) and are well supported. And "well supported" outweighs anything else anyway. I'm too old to run around in circles around nvidia or Intel, begging for even a binary only driver to get my machine to work at all.
Via is not as anal as Intel about their specs. Linux already has working support for the random number generator (their crypto extension), CPU frequency scaling (their SpeedStep/PowerNow equivalent), you aren't stuck with some proprietary and unsupported Intel wireless chipset, their USB, Firewire, Ethernet and IDE chips are proven technology and well supported by Linux, ...
and I'm told there is even support for their hardware MPEG-2 decoder now in mplayer (haven't actually tried it yet). All in all this is some sweet hardware, and I'd much rather buy Via than Intel chipsets. With Intel chipsets, if something is unsupported, you are basically on your own. In contrast, Via has actually come forward on the mplayer mailing list and asked for people willing to help add support for their MPEG-2 decoder extension. What else could you possible ask for?
Personally, I don't care about 10% chipset performance as long as I know Linux works on the damn thing. Just google for the troubles people are having running Linux on their Centrino notebooks and you will see what I mean.
By the way: I can play full-screen DVD and DivX even on my (older and supposedly much inferior) 933 MHz Ezra C3, with AC3 sound. It's just a question of the correct compiler switches. These CPUs are not as fast as an Athlon or a Pentium M, and I wouldn't want to transcode a DVD to MPEG-4 on them, but they are fast enough to do real work like software development. If these become available in Germany, I'll buy one.
Everyone likes to believe he is more productive than the rest of the world. I don't buy it. The facts are that the USA is importing much more than it is exporting, and this only works because the Dollar is the dominating currency and the US government can simply print more of them.
This is by the way a much more serious threat than WMD to the USA: that the Arab nations are considering switching to Euro. IIRC Iraq already did and Iran was thinking about it (or did they switch as well? Don't remember). Once the important economies switch to Euros, the Dollar will deflate very rapidly. Since practically nothing is actually produced in the USA anymore, there is nothing (apart from war) that the US government could actually be threatening anyone with. And once people don't depend on the Dollar, there is no reason to listen to the US government anymore.
THAT, my friend, is the real problem of the USA now. How did you believe the USA can survive pushing that giant debt around? The answer is: they can't, unless people don't care about their debt because they need more dollars for the international money exchange.
You might also want to read this article.
And apart from that: my personal statistics indicate that US IT workers are much less productive than others. You can measure it particularly well in the free software world. I suggest you take some time off (hehe) and do some statistics on Sourceforge mailing lists.
The smart boss will fire you and keep the normal guy who works 9 to 5. Why? Because he knows that you will break down eventually.
It's not in the best interest of a project manager to have his workers break down of exhaustion a few days before the deadline. In fact, if the project manager hires someone like you at all, it would be with great unease and you probably won't get the really important assignments, because you can't be trusted to survive this self-exploitation indefinitely. From the perspective of the business owner (I am one), I have more than enough troubles to worry about. Having my employees break down in the midst of an important assignment is not one of them.
Excessive hacker types like that are great for hacker parties and open source projects, where it does not matter in the real life. But in the end you burn out and I have never seen anyone who could keep his productivity up all the time. These people stend to stay in the company just as long (or some even stay progressively longer) but get less and less work done, because they are constantly fatigued.
Trust me, it's better for you, for the company, for your family AND for your boss if you just work normal hours. Competent project managers will actually prefer it if you spend less time at work as long as you get your stuff done. Dependability is more important than "I'll show 'em" self annihilation.
I didn't say the license is too restrictive.
I said the name was chosen to capitalize on the name of BIND, which is other people's work, basically.
All I'm saying is: you could have named it "vixdnsd" if you wanted people to use it on its own merits, not because they think they finally get a BIND version without all the pesky security problems.
It's the same as writing a web browser and calling it "Internet Explorer 7"; aside from trademark and copyright issues that's downright rude and a cheap way to capitalize on other people's work.