While Active Directory and NDS are widely used in the Microsoft and Novell worlds, LDAP has never been very popular in the Unix world. Most people even never heard about it.
LDAP is a standard protocol to access very modular hierarchical databases (called "directories" but anything can be stored in a LDAP directory, not only addresses) . It's way more flexible than SQL. You can redefine your own types and constraints (schema), all objects are extensible, all instances can belong to several classes, and anything that can fit in a tree can fit in a LDAP directory.
The first steps into LDAP aren't trivial. The syntax of LDIF files is a bit difficult to learn, but it's worth learning it.
There's an excellent open source LDAP server called OpenLDAP. It has support for LDAP version 3, SSL, IPv6, and everything you need to use LDAP. I've successfully installed it on large production servers. It's stable, and fast (if add your own indexes) .
Just like IPv6, LDAP for Unix is here for a long time (thanks, iPlanet), but it needs better integration with common software. If LDAP was implemented in all daemons and client software, it would ease a lot network administration. You can then configure all servers from a single workstation, in a coherent, unified database.
And for programmers, adding LDAP support is not a hell. Have a look at some OpenLDAP samples. I implemented LDAP support in Pure FTPd in less than one hour with no previous knowledge of the OpenLDAP API. The src/log_ldap.c is a simple getpwnam() wrapper and it can be reused by any program that use this library call to read/etc/passwd. It's a GPL package, so feel free to merge it to any piece of free software.
Also, Unix lacks good visual XML and LDAP editors. The recently announced Ganimede looks promizing, though. But if you are starting to learn LDAP, also give a try to GQ (sorry, I can't remember the URL, check it on Freshmeat) . It's a simple GTK tool to browse and edit LDAP directories and schemas.
These consoles have a limited memory amount, but they have fast processors, and they are really cheap. So they may be interesting for intensive computations (math) . If MPI / PVM / Mosix are properly working on this hardware, you can stack some of these and build a cheap and very efficient cluster.
But I've read several times that Sony and Microsoft will *loose* money by selling a XBOX or a PS2 box. The components are more expensive that how much these consoles are sold, because games will bring money. It's just like a cell phone business (cheap, even free phone, but you must subscribe an operator) .
If everyone starts using consoles as servers or workstations, maybe Microsoft and Sony will try to fight against this (well, Sony has a Linux distro, but they *sell* it to compensate the games you won't buy)
Yes, they have sold less records that the previous year. So what ? Just like any product, there are years better than previous ones, and years worse than previous ones.
I don't think that Napster change anything to CD sales. When you get something from Napster, it's just by curiosity. You want to hear what 's last album sounds like. Or listen to old silly goodies just to laugh your ass off. Nothing more. I seriously doubt that a guy who has downloaded a song from napster would have ever bought that song.
Music is not a product like an hair dryer. You buy a record because you love it and because you want to support the artist. You go to see live tours, you tell your friend about that artist because you want to share the pleasure you have listening to him. Napster or any artificial way to steal music will not have any influence on how people love music.
Psion 5 machines are also devices with limited power (8 mhz for 5, 16 mhz for 5mx), little memory, tiny screen, etc.
But the Psion web browser rocks. And Opera is even better.HTML 4 works. Javascript works. On 5MX, Java is also fully supported. And dithered pictures don't look that ugly. And it renders just as fast as Mozilla on my Celeron 450.
Assembly language and optimization. This point has been forgotten by today's developpers for servers and desktop computers.
When I coded demos on Atari ST, 1 cycle was 1 cycle (actually 4 on 68000), and it should never been lost, or another crew would have done better than your. And when you only have 512 K RAM total, you have to save bytes, too. Code was unpacked and generated on-the-fly, and every piece of hardware was used at its best. For instance, I used the sound hardware to draw 3D (actually to erase the virtual screen by sampling with no volume) . Generated code, precalculations, memory moves, self-modified code, pre-shifted line segments and sprites, etc. This was tricky, this was a hell to debug and to understand when you didn't fully design the code. But it was hard to do faster. We could spent one entiere year just to save some cycles in order to have the best sprite or line routine of all crews.
Today's workstations have 500x more memory that Atari ST had. Their CPU is 200x faster. And the graphic and sound chips are also able to do amazing things without the need of the main CPU (playing a soundtrack module at 16khz + fullscreen took just about 80% of the CPU time per VBL on Atari...) . So why don't we have applications that are at least 200x faster ?
Because there are no more real coders. Just programmers. People sometimes care about algorithms, not about the code itself. And nobody seems to have interest in assembly language. High-level bloated slow languages like Perl and PHP rules the world (no flame here : I love Perl, but the fact is that the same thing could be 100x faster in execution. But 100x longer to code, yes) . I can't imagine what wonderful things we could have on our PC today if everything was coded like good old demos.
And big projects can be coded in pure assembly. The GfA-Basic and Devpac 2 were powerful development kits (interpreter/compiler/assembler/debugger) and 100% pure assembly. The same things goes for HP48 projects. 100% Saturn assembly (hi HP freaks ! HPdream is talking to you !), and there were monster projects (like the meta-kernel, now in newer HP calculators) .
Some big demos also needed a lot of source code, twice the size of the linux kernel source code. And it worked. Fast.
Coding in pure assembly nowadays may sound like regression. But maybe fast and lazy programming to get a just-working but slow and bloated result is also a regression.
"Not releasing the source code would solve many security problems"
I disagree. Not releasing the source code means that :
Users can't trust any program because backdoors can be hidden. Remember Interbase ?
When users discover a hole, they can't fix it. Even if they are very skilled programmers and the fix is an oneliner. They can't. They have to wait for a patch from the vendor / authors. And while the patch isn't released, they are vulnerable.
Users can't help the development team to fix holes.
If you read Bugtraq you will notice that Windows applications have tons of security holes. But the number of holes is not important. The important thing is that often, a security advisory ends up with "Vendor has been contacted... no response so far... no known fix... no workaround..." . And what can vulnerable users do in this case ? Nothing. Wait. Pray that nobody will see the breach. Wait until the vendor wakes up. If he ever does.
Also, remember that most closed-source encrypto schemes were hacked (decss, anyone ?) .
When you don't trust a host with your source or binary code, store the MD5 or SHA1 sum somewhere else.
The BSD "ports" tree is very well designed for this. The MD5 sum is stored on *BSD mirrors, and the files are fetched from various locations (like Sourceforge) . When a port has to be built, the source code is fetched and compared with the awaited MD5 sum. If the sum differs from the computed one, a bigfatwarning appears and installation stops.
I guess Debian packages fetched through apt-get have something like this, too.
For other package or source code, put MD5 / SHA1 sums on another web site. But well... unfortunately in the real world, users will never check the sum.
And this doesn't protect the CVS tree from being trojanized. But the CVS tree is another story. When a developper types 'cvs update' or 'cvs commit' and discovers odd changes (for instance on the part he -and nobody else- is working), he can discover the trojan and reset the tree to a sane state.
In all cases, the open source world depends on trusted relationships. Sourceforge has the power to put trojans in all major open source projects and it would hurt a lot. The same thing goes for Tucows, Ibiblio.org, etc. Developers have to trust these free hosting services. End users have also to trust them. End users should also trust developers. There are many popular projects with only one developper, so nobody would review the code while an hidden trojan is making disaster.
But open source developers and hosting services are clean. Everybody is trusting each other. While any of them could create severe damage to the open source world, it doesn't happen. This is a question of mentality. On some commercial operating systems, trojans and viruses are common, and people never install new software without running an antivirus.
An interesting thing is that Todd Fries bought the openipf.org domain on May 25.
Todd contributes to many opensource projects, like OpenSSH .
So maybe it means that IPF have the same future than SSH : a really free implementation will follow.
At the same time, Linux Netfilter is growing. While it's not as mature as IPFilter, it's definitely featureful, and going in the right direction.
So maybe the BSD folks can work with the Netfilter dudes instead of reinventing the wheel. We would get only one free packet filtering system, but common to many system, with many developpers, and that would beat everything.
Porting Netfilter to BSD systems is not impossible. Internal socket structures are different, but the way protocols are analyzed can be left unchanged. And it should be also easy to code a parser that would rewrite IPF rules into Netfilter rules, so that people would be able to easily migrate.
There's nothing wrong with Motif. It has been designed from scratch to be extensible and it can still get improvements over years.
I've written Motif, QT, Gtk, Photon (QNX) and Fltk apps. They all work the same way. The basic widgets are the same, and when you've learn how to code one, you can easily move to another one. They all work on a hierarchical component model, with inheritable attributes, and an event-based system.
For some apps, especially those who are dynamically building widgets, QT and GTK are easier to program. And libglade is something worth to look at. It goes one step further than other toolkits, because an user can build his own interface for any compliant app, not only customize an existing one with themes or colors. For widgets with dynamic content (lists, panes), Photon (on QNX) beats them all. It's easy to code, smooth and damn fast.
The only problem with Motif IMHO is that it eats up a lot of memory. Especially when you are using nested scrolling panes. Properly using widgets and gadgets can reduce the memory footprint, but it's always huge. It's not the size of the Motif library itself, but the amount of dynamic memory it requires for itself and from the X server. I can't run more than 3 or 4 different Motif apps at the same time without running out of memory (128 Mb) . Other toolkits don't seem to need so much memory, even with complex themes.
The FLTK toolkit isn't very popular. But it's really a very good one. It's LGPL'ed, and it has X, OpenGL and Windows backends. It's fast and lightweight. And it has many similarities with QT. If you want to write an applications with basic widgets in C++, try FLTK before QT. It's not easier to code, but your apps will run faster (at least the GUI part) . FLTK also comes with FLUID, an efficient interface builder.
just adding a link to a big disclaimer ? Maybe just a line like :
Reading this message assumes you've read http://...
That's funny anyway. Basically, emails disclaimers are saying "warning : maybe the content of this message has been modified by a third party" .
But well... why would the third party modify the message body but leave the disclaimer ?
That's pointless.
To send a message that has to be trusted :
Send a mail to the recipient with a link. The link should point to a web server that belongs to the company of the mail sender.
Have the recipient follow the link and fetch the message through HTTPS.
The mail content can't be forged (excepted if the mail/web servers got rooted) .
The sender knows that the recipient has read the message. He knows when. He knows from which IP it happened. If he feels paranoid, he can allow browsing messages only after authentication or specific IP.
But of course, spammers may use this to validate addresses they have sent fake important messages to. Fighting spammers stupidity is an endless war.
Maybe IPv6 isn't widely deployed because of the lack of compatible applications. Many programmers don't make a step to have their apps work with IPv6.
I've written a french IPv6 programming HOWTO to help these people port IPv4-only apps to IPv6.
IPv6 is something really worth to look at.
In the real life, a gorgeous girl will get the stuff for free. With a drink and extra money.
A salesman will buy it at a high price, but he will tell his boss he had a 40% discount. But he had to pay the restaurant to his partner for this (thanks to the company's credit card) .
A programmer will try to reverse-engineer the product/price crypto hash, he will finally find this is just another random() function, so he will buy the product at a random price.
A kernel hacker will wait until the price increases over 2^31-1 so that he would finally be negative, and the kernel hacker will be rich.
A hardware hacker will think that variable prices are due to variable electric intensity and consensators filling. He will get it from a californian reseller (without electricity, prices should be lower) .
Microsoft will think that variable prices shouldn't exist in May 2001. Because piracy is illegal and Windows XP is not released yet.
They will sell commercial support and consultancy. They can go to your company, check what computers the game would be the best on, sell you new hardware, build a new network infrastructure optimized for the game and sell you a new firewall which recognizeds this new protocol. Of course your employees needs to learn the new game. So the company will give curses, given by 15 very skilled professors, that know every secret of the game. When they will be back, your company can still call an hotline to ask for secrets the previous guys didn't speak about (hidden levels, secret keystrokes for unlimited life and power...) .
Then, no one in your company will be doing his real job any more. They will sell you coffee and drugs so that you can play 23 hours a day, and still be okay to do your real job 1 hour a day.
You will be charged $ 1.000.000 for this. And with the bill, they will send you a special offer to buy their next game.
Babelfish translator has lost his creator and maintainer.
Who will feed the fish, now ?
Maybe we should give the babelfish to Theo de Raadt, so that OpenBSD will run all hardware (past, present and future) over the universe ? And we will give back the ex-OpenBSD blowfish to the Altavista dudes, they won't see any change, anyway.
Maybe Douglas wrote (or started to write) things that never were published (Hitchiker's guide #6 ?) . They will maybe be revealated now.
Rest in Peace, Douglas. We love you.
Please, everyone, when you write documentation, and when you need an arbitrary number, use 42.
Maybe we also should release a patch for 'bc' and every calculator so that 6*9 = 42.
Linux doesn't cries for browser plug-ins. Major plug-ins (real, acrobat, flash, vrml...) are already native Linux implementations.
A major step would be to allow Linux to run Windows hardware drivers. Many people are still keeping a Windows partition because there's no Linux driver for their printer (or not photo-quality), no driver for their (win)modem, and sometimes there's no hope and no way to help because hardware specifications are (and will remain) closed.
The same thing could apply to other architectures as well. Almost every piece of hardware comes with MacOS drivers. Maybe it would be possible to code a glue in order to use them on Linux/PPC.
Yes, natives drivers will always be better. But this trick would be better than no hardware support at all.
If it is possible to code something able to run every Windows browser plug-ins, I guess the same technology can also server device drivers. So why not focus on this instead ?
Some people are yelling because Opera isn't FREE as in FREE SPEECH. But if it was an opensource project, will these people get into the source to improve and debug it ? Probably not.
Mozilla is opensource. Who's working on it ? Almost the same team since the beginning. Openoffice is opensource. Who's working on it ? Only the original StarOffice coders. The fact is that it's hard to contribute to very large projects.
I tried to understand the Mozilla source code, but I never was able to understand the whole mecanism. It's designed in a very clever way, but even with documentation, understanding it is a worthy challenge.
There's a reason for DJB software licence.
What if someone takes Qmail, adds unofficial patches to it, releases it in binary form in a distro, and holes are found (due to the addition) ? People will yell "Qmail sucks, Qmail is insecure, a serious flaw was discovered !" .
Qmail will loose credibility, because of something his author never comitted.
DJB licence allows you to distribute the original source code, plus patches. And you can build the whole thing. It's allowed and free, so you *can* have your own improvements to DJB software. But these patches must be in a separate package, not merged in the original tarball. Everyone can check what additions are done to the software. And everyone know that there's a safe base.
It also avoids bloat. If I need LDAP with Qmail, I add the patch. If I don't need LDAP, I use a vanilla Qmail package, and I know that there is no code I won't use in it. I have something that perfectly fits my needs. It improves efficiency and security. It's just like installing OpenBSD. You have a minimal audited base, and everyone adds his own bloat according to his needs.
Now for Linux distributions... Can't you provide a package that will self-recompile ? That way, you can include Qmail and djbDNS in Redhat. You can fix holes and add Redhat-specific features if you want. SRPMS are done for this, aren't they ? It doesn't choke a newbie, building and installing SRPMS are just like RPMS. Nothing to configure, no 'make' to type. Debian package can also recompile themselves from source code.
Also, please have a look at Gentoo Linux . A new Linux distro that relies on daemontools, djbdns, qmail, ip, reiserfs, etc.
Did Casio build other computers before ?
When you buy a Sony or Toshiba laptop, you can always call the vendor to ask him what extensions can be plugged, where to find BIOS updates, why their hardware doesn't work with some piece of software, etc. These vendors are selling laptops for years, and they have a solid technical and commercial support for their computers.
But what about Casio ? They are experienced with watches and calculators, but I doubt they have a large technical support for their laptop.
It also means that they can drop support for their laptop whenever they want. And you won't have BIOS and driver updates to install latest Windows releases.
A laptop is quite expensive, and you can't just change internal hardware as easily as on a traditional box. It's why the vendor is an important factor in your decision of buying one.
XFS is still an external patch, it's not included in the official kernel. And it seems that there is a delay between a new kernel release and a new XFS version for that kernel.
XFS 1.0 is against kernel 2.4.2 . Or 2.4.3, but SGI says it may be instable with this version.
But the current kernel is 2.4.4 (or 2.4.4-ac2) .
And 2.4.4 fixes important problems that previous kernels had. For instance, it fixes serious security flaws in Netfilter.
So, today, you can either run XFS, or get a fixed kernel. Not both.
This is why I'll stay with ReiserFS, until XFS get officially included in the kernel.
Slashdot Mirror
While Active Directory and NDS are widely used in the Microsoft and Novell worlds, LDAP has never been very popular in the Unix world. Most people even never heard about it. /etc/passwd. It's a GPL package, so feel free to merge it to any piece of free software.
LDAP is a standard protocol to access very modular hierarchical databases (called "directories" but anything can be stored in a LDAP directory, not only addresses) . It's way more flexible than SQL. You can redefine your own types and constraints (schema), all objects are extensible, all instances can belong to several classes, and anything that can fit in a tree can fit in a LDAP directory.
The first steps into LDAP aren't trivial. The syntax of LDIF files is a bit difficult to learn, but it's worth learning it.
There's an excellent open source LDAP server called OpenLDAP. It has support for LDAP version 3, SSL, IPv6, and everything you need to use LDAP. I've successfully installed it on large production servers. It's stable, and fast (if add your own indexes) .
Just like IPv6, LDAP for Unix is here for a long time (thanks, iPlanet), but it needs better integration with common software. If LDAP was implemented in all daemons and client software, it would ease a lot network administration. You can then configure all servers from a single workstation, in a coherent, unified database.
And for programmers, adding LDAP support is not a hell. Have a look at some OpenLDAP samples. I implemented LDAP support in Pure FTPd in less than one hour with no previous knowledge of the OpenLDAP API. The src/log_ldap.c is a simple getpwnam() wrapper and it can be reused by any program that use this library call to read
Also, Unix lacks good visual XML and LDAP editors. The recently announced Ganimede looks promizing, though. But if you are starting to learn LDAP, also give a try to GQ (sorry, I can't remember the URL, check it on Freshmeat) . It's a simple GTK tool to browse and edit LDAP directories and schemas.
These consoles have a limited memory amount, but they have fast processors, and they are really cheap. So they may be interesting for intensive computations (math) . If MPI / PVM / Mosix are properly working on this hardware, you can stack some of these and build a cheap and very efficient cluster.
But I've read several times that Sony and Microsoft will *loose* money by selling a XBOX or a PS2 box. The components are more expensive that how much these consoles are sold, because games will bring money. It's just like a cell phone business (cheap, even free phone, but you must subscribe an operator) .
If everyone starts using consoles as servers or workstations, maybe Microsoft and Sony will try to fight against this (well, Sony has a Linux distro, but they *sell* it to compensate the games you won't buy)
Yes, they have sold less records that the previous year. So what ? Just like any product, there are years better than previous ones, and years worse than previous ones.
I don't think that Napster change anything to CD sales. When you get something from Napster, it's just by curiosity. You want to hear what 's last album sounds like. Or listen to old silly goodies just to laugh your ass off. Nothing more. I seriously doubt that a guy who has downloaded a song from napster would have ever bought that song.
Music is not a product like an hair dryer. You buy a record because you love it and because you want to support the artist. You go to see live tours, you tell your friend about that artist because you want to share the pleasure you have listening to him. Napster or any artificial way to steal music will not have any influence on how people love music.
Psion 5 machines are also devices with limited power (8 mhz for 5, 16 mhz for 5mx), little memory, tiny screen, etc.
But the Psion web browser rocks. And Opera is even better.HTML 4 works. Javascript works. On 5MX, Java is also fully supported. And dithered pictures don't look that ugly. And it renders just as fast as Mozilla on my Celeron 450.
Assembly language and optimization. This point has been forgotten by today's developpers for servers and desktop computers.
When I coded demos on Atari ST, 1 cycle was 1 cycle (actually 4 on 68000), and it should never been lost, or another crew would have done better than your. And when you only have 512 K RAM total, you have to save bytes, too. Code was unpacked and generated on-the-fly, and every piece of hardware was used at its best. For instance, I used the sound hardware to draw 3D (actually to erase the virtual screen by sampling with no volume) . Generated code, precalculations, memory moves, self-modified code, pre-shifted line segments and sprites, etc. This was tricky, this was a hell to debug and to understand when you didn't fully design the code. But it was hard to do faster. We could spent one entiere year just to save some cycles in order to have the best sprite or line routine of all crews.
Today's workstations have 500x more memory that Atari ST had. Their CPU is 200x faster. And the graphic and sound chips are also able to do amazing things without the need of the main CPU (playing a soundtrack module at 16khz + fullscreen took just about 80% of the CPU time per VBL on Atari...) . So why don't we have applications that are at least 200x faster ?
Because there are no more real coders. Just programmers. People sometimes care about algorithms, not about the code itself. And nobody seems to have interest in assembly language. High-level bloated slow languages like Perl and PHP rules the world (no flame here : I love Perl, but the fact is that the same thing could be 100x faster in execution. But 100x longer to code, yes) . I can't imagine what wonderful things we could have on our PC today if everything was coded like good old demos.
And big projects can be coded in pure assembly. The GfA-Basic and Devpac 2 were powerful development kits (interpreter/compiler/assembler/debugger) and 100% pure assembly. The same things goes for HP48 projects. 100% Saturn assembly (hi HP freaks ! HPdream is talking to you !), and there were monster projects (like the meta-kernel, now in newer HP calculators) . Some big demos also needed a lot of source code, twice the size of the linux kernel source code. And it worked. Fast.
Coding in pure assembly nowadays may sound like regression. But maybe fast and lazy programming to get a just-working but slow and bloated result is also a regression.
"of course, it runs NetBSD !"
The Open Baby will recode IPF from scratch. Just give her some time.
If IPF has to be recoded from scratch, it will loose his maturity.
I disagree. Not releasing the source code means that :
If you read Bugtraq you will notice that Windows applications have tons of security holes. But the number of holes is not important. The important thing is that often, a security advisory ends up with "Vendor has been contacted... no response so far... no known fix... no workaround..." . And what can vulnerable users do in this case ? Nothing. Wait. Pray that nobody will see the breach. Wait until the vendor wakes up. If he ever does.
Also, remember that most closed-source encrypto schemes were hacked (decss, anyone ?) .
When you don't trust a host with your source or binary code, store the MD5 or SHA1 sum somewhere else.
The BSD "ports" tree is very well designed for this. The MD5 sum is stored on *BSD mirrors, and the files are fetched from various locations (like Sourceforge) . When a port has to be built, the source code is fetched and compared with the awaited MD5 sum. If the sum differs from the computed one, a bigfatwarning appears and installation stops.
I guess Debian packages fetched through apt-get have something like this, too.
For other package or source code, put MD5 / SHA1 sums on another web site. But well... unfortunately in the real world, users will never check the sum.
And this doesn't protect the CVS tree from being trojanized. But the CVS tree is another story. When a developper types 'cvs update' or 'cvs commit' and discovers odd changes (for instance on the part he -and nobody else- is working), he can discover the trojan and reset the tree to a sane state.
In all cases, the open source world depends on trusted relationships. Sourceforge has the power to put trojans in all major open source projects and it would hurt a lot. The same thing goes for Tucows, Ibiblio.org, etc. Developers have to trust these free hosting services. End users have also to trust them. End users should also trust developers. There are many popular projects with only one developper, so nobody would review the code while an hidden trojan is making disaster.
But open source developers and hosting services are clean. Everybody is trusting each other. While any of them could create severe damage to the open source world, it doesn't happen. This is a question of mentality. On some commercial operating systems, trojans and viruses are common, and people never install new software without running an antivirus.
An interesting thing is that Todd Fries bought the openipf.org domain on May 25.
Todd contributes to many opensource projects, like OpenSSH .
So maybe it means that IPF have the same future than SSH : a really free implementation will follow.
At the same time, Linux Netfilter is growing. While it's not as mature as IPFilter, it's definitely featureful, and going in the right direction.
So maybe the BSD folks can work with the Netfilter dudes instead of reinventing the wheel. We would get only one free packet filtering system, but common to many system, with many developpers, and that would beat everything.
Porting Netfilter to BSD systems is not impossible. Internal socket structures are different, but the way protocols are analyzed can be left unchanged. And it should be also easy to code a parser that would rewrite IPF rules into Netfilter rules, so that people would be able to easily migrate.
There's nothing wrong with Motif. It has been designed from scratch to be extensible and it can still get improvements over years.
I've written Motif, QT, Gtk, Photon (QNX) and Fltk apps. They all work the same way. The basic widgets are the same, and when you've learn how to code one, you can easily move to another one. They all work on a hierarchical component model, with inheritable attributes, and an event-based system.
For some apps, especially those who are dynamically building widgets, QT and GTK are easier to program. And libglade is something worth to look at. It goes one step further than other toolkits, because an user can build his own interface for any compliant app, not only customize an existing one with themes or colors. For widgets with dynamic content (lists, panes), Photon (on QNX) beats them all. It's easy to code, smooth and damn fast.
The only problem with Motif IMHO is that it eats up a lot of memory. Especially when you are using nested scrolling panes. Properly using widgets and gadgets can reduce the memory footprint, but it's always huge. It's not the size of the Motif library itself, but the amount of dynamic memory it requires for itself and from the X server. I can't run more than 3 or 4 different Motif apps at the same time without running out of memory (128 Mb) . Other toolkits don't seem to need so much memory, even with complex themes.
The FLTK toolkit isn't very popular. But it's really a very good one. It's LGPL'ed, and it has X, OpenGL and Windows backends. It's fast and lightweight. And it has many similarities with QT. If you want to write an applications with basic widgets in C++, try FLTK before QT. It's not easier to code, but your apps will run faster (at least the GUI part) . FLTK also comes with FLUID, an efficient interface builder.
Reading this message assumes you've read http://...
That's funny anyway. Basically, emails disclaimers are saying "warning : maybe the content of this message has been modified by a third party" .
But well... why would the third party modify the message body but leave the disclaimer ?
That's pointless.
To send a message that has to be trusted :
But of course, spammers may use this to validate addresses they have sent fake important messages to. Fighting spammers stupidity is an endless war.
Yes. That'd be a benchmark :)
Maybe IPv6 isn't widely deployed because of the lack of compatible applications. Many programmers don't make a step to have their apps work with IPv6.
I've written a french IPv6 programming HOWTO to help these people port IPv4-only apps to IPv6.
IPv6 is something really worth to look at.
"Peace, love and Cindy Crawford" ?
Will I be forced to make love with Cindy during 30 days ?
In the real life, a gorgeous girl will get the stuff for free. With a drink and extra money.
A salesman will buy it at a high price, but he will tell his boss he had a 40% discount. But he had to pay the restaurant to his partner for this (thanks to the company's credit card) .
A programmer will try to reverse-engineer the product/price crypto hash, he will finally find this is just another random() function, so he will buy the product at a random price.
A kernel hacker will wait until the price increases over 2^31-1 so that he would finally be negative, and the kernel hacker will be rich.
A hardware hacker will think that variable prices are due to variable electric intensity and consensators filling. He will get it from a californian reseller (without electricity, prices should be lower) .
Microsoft will think that variable prices shouldn't exist in May 2001. Because piracy is illegal and Windows XP is not released yet.
They will sell commercial support and consultancy. They can go to your company, check what computers the game would be the best on, sell you new hardware, build a new network infrastructure optimized for the game and sell you a new firewall which recognizeds this new protocol. Of course your employees needs to learn the new game. So the company will give curses, given by 15 very skilled professors, that know every secret of the game. When they will be back, your company can still call an hotline to ask for secrets the previous guys didn't speak about (hidden levels, secret keystrokes for unlimited life and power...) .
Then, no one in your company will be doing his real job any more. They will sell you coffee and drugs so that you can play 23 hours a day, and still be okay to do your real job 1 hour a day.
You will be charged $ 1.000.000 for this. And with the bill, they will send you a special offer to buy their next game.
This is how to make money with GPL games.
Babelfish translator has lost his creator and maintainer.
Who will feed the fish, now ?
Maybe we should give the babelfish to Theo de Raadt, so that OpenBSD will run all hardware (past, present and future) over the universe ? And we will give back the ex-OpenBSD blowfish to the Altavista dudes, they won't see any change, anyway.
Maybe Douglas wrote (or started to write) things that never were published (Hitchiker's guide #6 ?) . They will maybe be revealated now.
Rest in Peace, Douglas. We love you.
Please, everyone, when you write documentation, and when you need an arbitrary number, use 42.
Maybe we also should release a patch for 'bc' and every calculator so that 6*9 = 42.
Linux doesn't cries for browser plug-ins. Major plug-ins (real, acrobat, flash, vrml...) are already native Linux implementations.
A major step would be to allow Linux to run Windows hardware drivers. Many people are still keeping a Windows partition because there's no Linux driver for their printer (or not photo-quality), no driver for their (win)modem, and sometimes there's no hope and no way to help because hardware specifications are (and will remain) closed.
The same thing could apply to other architectures as well. Almost every piece of hardware comes with MacOS drivers. Maybe it would be possible to code a glue in order to use them on Linux/PPC.
Yes, natives drivers will always be better. But this trick would be better than no hardware support at all.
If it is possible to code something able to run every Windows browser plug-ins, I guess the same technology can also server device drivers. So why not focus on this instead ?
Some people are yelling because Opera isn't FREE as in FREE SPEECH. But if it was an opensource project, will these people get into the source to improve and debug it ? Probably not. Mozilla is opensource. Who's working on it ? Almost the same team since the beginning. Openoffice is opensource. Who's working on it ? Only the original StarOffice coders. The fact is that it's hard to contribute to very large projects. I tried to understand the Mozilla source code, but I never was able to understand the whole mecanism. It's designed in a very clever way, but even with documentation, understanding it is a worthy challenge.
There's a reason for DJB software licence. What if someone takes Qmail, adds unofficial patches to it, releases it in binary form in a distro, and holes are found (due to the addition) ? People will yell "Qmail sucks, Qmail is insecure, a serious flaw was discovered !" . Qmail will loose credibility, because of something his author never comitted. DJB licence allows you to distribute the original source code, plus patches. And you can build the whole thing. It's allowed and free, so you *can* have your own improvements to DJB software. But these patches must be in a separate package, not merged in the original tarball. Everyone can check what additions are done to the software. And everyone know that there's a safe base. It also avoids bloat. If I need LDAP with Qmail, I add the patch. If I don't need LDAP, I use a vanilla Qmail package, and I know that there is no code I won't use in it. I have something that perfectly fits my needs. It improves efficiency and security. It's just like installing OpenBSD. You have a minimal audited base, and everyone adds his own bloat according to his needs. Now for Linux distributions... Can't you provide a package that will self-recompile ? That way, you can include Qmail and djbDNS in Redhat. You can fix holes and add Redhat-specific features if you want. SRPMS are done for this, aren't they ? It doesn't choke a newbie, building and installing SRPMS are just like RPMS. Nothing to configure, no 'make' to type. Debian package can also recompile themselves from source code. Also, please have a look at Gentoo Linux . A new Linux distro that relies on daemontools, djbdns, qmail, ip, reiserfs, etc.
Did Casio build other computers before ? When you buy a Sony or Toshiba laptop, you can always call the vendor to ask him what extensions can be plugged, where to find BIOS updates, why their hardware doesn't work with some piece of software, etc. These vendors are selling laptops for years, and they have a solid technical and commercial support for their computers. But what about Casio ? They are experienced with watches and calculators, but I doubt they have a large technical support for their laptop. It also means that they can drop support for their laptop whenever they want. And you won't have BIOS and driver updates to install latest Windows releases. A laptop is quite expensive, and you can't just change internal hardware as easily as on a traditional box. It's why the vendor is an important factor in your decision of buying one.
The youngest OpenBSD hacker is a girl. Check that link .
XFS is still an external patch, it's not included in the official kernel. And it seems that there is a delay between a new kernel release and a new XFS version for that kernel.
XFS 1.0 is against kernel 2.4.2 . Or 2.4.3, but SGI says it may be instable with this version.
But the current kernel is 2.4.4 (or 2.4.4-ac2) .
And 2.4.4 fixes important problems that previous kernels had. For instance, it fixes serious security flaws in Netfilter.
So, today, you can either run XFS, or get a fixed kernel. Not both.
This is why I'll stay with ReiserFS, until XFS get officially included in the kernel.