The problem is that the amount of data on our disks keeps growing and growing, while our tools to index and search that data are designed with only small filesystems (like, 40 MB) in mind.
Imagine a filesystem in which you can store your email, and that the filesystem can be made to understand your mail. Want all mails sent by John Doe to you? The filesystem knows the answer.
If your email application is aware of the database driven filesystem, it does not have to implement its own mailstore. Currently the application has to use mbox, maildir, or some other format.
Of course, it doesn't end there. What about the user database, currently stored in/etc/passwd? The format is flawed, proved by the existence of/etc/shadow and setuid tools for mortals to edit them. Why not make a simple password file which only contains the encrypted password which a user can edit?
The possibilities don't end there. All files with some internal structure can be stored in the db-fs.
No more mp3's with a hacked md3 tag in them. Just store the metadata where it belongs: outside the data stream.
A db-fs will dramatically alter the way we work with computers. It truly is the next step in computing. Therefore, it will also take a LOT of time before it is implemented. 10 years at least.
If it's hard to understand what such a system would look like: imagine you store all your data into an SQL database. Yes, that's a lot of change.
Worried about the bloat? Bloat is no problem. First of all, since we won't have a db-fs for another 4 years or so, with widespread acceptance 10 years from now, our computers will be WAY faster than what we're using now. Secondly, a db-fs won't be a full-blown SQL database. The kernel only implements some primitives, while userspace libraries implement the actual logic, the 'meat' of the system. Since kernel memory cannot be swapped out, this matters a lot. Finally, what bloat is today, is necesary tomorrow. Imagine an oracle database on hardware from the seventies. Bloated beyond imagination, dog slow. But since the seventies the amount of data stored in a database has grown tremendiously, to the level where we simply need databases like Oracle or SQL Server to store it. Luckaly, the hardware to run it on has grown to.
No, the only real big obstacle to a db-fs is user ignorance. Or conservatism. People either won't understand its importance, or won't want to change.
Once Longhorn is out, it will take a few years for them to understand what's going on, and OSS is up to chasing taillights once again. Please don't let it come that far and start thinking about db-fs'es now.
The KDE mime database can be found in the control center under KDE Components-> File Associations.
For each mimetype you can add a list of handler applications and a list of embeddable parts, called KParts.
All I/O is handled by the KIO subsystem, which has handlers for about any protocol which can transfer files, including local disk, http, ftp. All KDE applications (and KParts) use the KIO system, so all KDE applications can read and write data from and to all protocols.
The communications protocol is called DCOP, and yes, it's object oriented. Don't know whether it's a bus or a point-to-point protocol though. It's very easy to use though, even from shellscripts.
In my experience, this is exacly the problem in the usability discussion. Most people completely miss the point, saying that after countless tweaks which are very hard to implement for a novice user, the system works just fine.
IMHO, they take the easy way out. Making a system usable by default is hard. Very hard.
Except that.com isn't the first TLD to perform rapid updates. AFAIK.info already does this. So spammers can move sites quickly today. No change in that.
You're wrong. KDE is very modular due to its DCOP, kpart and KIO protocols. If some app needs a text editor, it simply incorporates a kpart which implements the editor. And if the app needs to load text documents from the network, it simply uses the KIO slaves for http, ftp, etc. And if it needs some information that another running app has, it simply does a DCOP call.
So, KDE is built with small parts and tools, they're just very nicely intergrated.
However, I'm supprised that no really bad security holes in konqueror have been discovered yet. Browser and file manager intergrated is very nice, but also very scary...
The fact that they spent three years integrating anything from "explorer.exe" to the kernel with IE?
It's not intergrated with the kernel. It's intergrated with the OS. MSIE is basically a set of libraries used by lots of applications, including msie.exe-the-browser.
You can compare msie intergration into the Windows OS with khtml intergration into KDE. You simply cannot rip khtml out of KDE without breaking a bunch of (critical) applications. Same goes with MSIE.
Very few applications are purely CPU based. Most applications wait for the user to decide what he/she wants to do.
The speed of interactive applications is mainly limited by the user operating it. So, the application should aid the user in the process of making descisions.
Part of this aid is making the application less suprising. Should a sidebar pop up at the left side of a window as quickly as possible, or should it 'slide' in in a few tens of a second? The slide does grab the user's attention, which could lead to an overall speedup in the work actually done by the user.
This Sun desktop may also aid the user. The user is working more efficiently at the expense of CPU cycles. But hey, isn't that exacly what computing is about?
And that's exactly why assembly is mostly irrelevant (with a few exceptions, of course).
Assembly is faster than C only if you have a lot of time to spare. And C is faster than [your favorite higher lever language here] only if you have lots and lots of time to spare.
The problem is: there is no REALLY good high level language for generic application development (things like word processors, web browsers, etc).
However, a language like C# could become such a thing.
I think that in a few years time only the time critical parts of an application are written in C and the hardware dependant parts are written in assembly. For all the rest there is [insert future high level language here].
Using apt4rpm I just completed a dist-upgrade. I have had a few major problems:
The shadow package is now called 'pwdutils'. This confuses apt a lot
During the installation of the 'devs' rpm (containing/dev) apt segfaulted. I'm not sure if this was caused by the installation of devs or due to a corrupted rpm database. A 'rpm --rebuilddb' fixed it for me
The (unofficial!) KDE 3.2 packages in the Suse 9.0 repository have identical version numbers as the Suse 9.1 rpms, it seems. However, the dependencies differ. You'll have to remove KDE and reinstall
My overall impression of the distro so far is that it's suse 9.0, but slightly better.
There are two kinds of speed: things that are fast and things that feel fast.
The article and the comments here on/. are mainly talking about true benchmarkable speed. Things that are fast.
But some apps don't really need to be fast. They just have to feel fast. This holds true for most interactive applications. It's all about psycholigy with this one.
Ever wondered why Windows Explorer builds up its icons from the right bottom to the top left? Doesn't matter in real speed, but it just feels faster. Your brain just isn't used to this flow: usually you read from the top left to the bottom right, or you read from the top right to the bottom left. Your eyes immediately focus on the spot your brain expects the icons to appear. But instead the appear in the opposite corner. By the time your brain figures out it has been tricked, the window is already full of icons.
More tricks: ever wondered why windows wastes memory by trying to have some free memory ready all the time? It makes starting new apps faster. But on average the system is slower.
In the Unix world there is only raw, benchmarkable speed. And that's why KDE and Gnome are slow. They aren't slow, they just feel slow.
Klipper is nice, but make sure you exclude Firefox from it. Somehow Klipper makes Firefox progressively slower and after a few hours of use firefox just crashes.
Withour Klipper Firefox runs for days without crashes, and fast as ever.
I've had a similar problem on my LAN. Large packets would always be corrupted, while small packets would get trough.
Well, it wasn't really a lan. It was two computers with a crosscable between them. The problem: one of the computers is a Duron and the user installed a power-management tool on his computer. The tool put the processor in sleep mode when idle (no, not HLT, but a deeper sleep mode). Problem was: not all old Duron/Athon boards correctly support this sleep mode. The power supply was generating spikes, which were evidentely picked up by the NIC and relayed to the network.
Re:you will pry debian out of my cold dead hands .
on
Suse 9.1 Reviews?
·
· Score: 2, Informative
+5 Troll.
First of all: rpm is both a format an a tool. Both are fine. The format used in debian is deb and the tool used in debian is dpkg. Both are fine too.
Suse's apt-get equivalent is yast. But if you don't like yast, just install apt.
Second: yast md5sums all your configfiles and refuses to overwrite any modified files:
dexter:~ # SuSEconfig --module apache Starting SuSEconfig, the SuSE Configuration Tool... Running module apache only Reading/etc/sysconfig and updating the system... Executing/sbin/conf.d/SuSEconfig.apache...
ATTENTION: You have modified/etc/httpd/httpd.conf. Leaving it untouched... You can find my version in/etc/httpd/httpd.conf.SuSEconfig...
Sure, and both Linux 2.4 and 2.6 do caching and read-ahead (reading more data than requested, hoping that the application will request the data in the future).
The I/O scheduler however lies beneath the cache layer. When it's decided that data must be read from or written to disk, the request is placed in a queue. The scheduler may reorder the queue in order to minimize head movements.
Also, 2.6 has the anticipatory I/O scheduler: after a read, the scheduler simply pauses for a (very) short period. This is done in the assumption that the application will request more data from the same general area on the disk. Even when other requests are in the I/O queue, requests to the area where the disk's heads are hovering will get priority.
While this increases latency (the time it takes for a request to be processed) a bit, throughput (the amount of data transfered in a time period) will also increase.
It did take a fair amount of experimenting and tuning in order to make the I/O scheduler work as well as it does now. However there still may be some corner cases where the new scheduler is much slower than the old.
Re:What about Slashdot?
on
CSS for the LDP?
·
· Score: 2, Informative
CSS makes pages more accessible from lynx. So, yes.
It seems to be confusing that one can buy a commercial version of Qt. That version however is extra. If you don't want it, just stick to plain old GPL'ed Qt.
MySQL is doing something similar. Nobody seems to be confused by that one though.
I have to agree. C is not suitable for general application development any more. 'back in the day' we were forced to use C because of performance reasons, but now computers have more than enough horsepower to run higher-level languages smoothly.
You can already see this with web applications: almost nobody writes them in C. They use PHP or Perl. There languages are just far better suited for web development than C.
It may well be that Mono/C# is becoming more suited for general application development than C. Or maybe Python. Or Perl.
I think that in the not-so-distant future C will only be used at places where performance really counts, hidden deep away in libraries and the operating system.
The advantage of replacing C with a higher level language: programmers will be able to concentrate more on the application they're writing and less on the low-level things like coding linked lists, hash tables, etc. This will improve the quality of the applications. Or make applications more complex with constant quality.
An advantage of C#: developers will be able to distribute just one binary version of their application, it'll run on any platform. Not very important in the world of Open Source, but still a nice thing to have.
The 'trick' is to create a corrupt partition table
on
Recovering Secret HD Space
·
· Score: 5, Insightful
You should see an 8 meg partition labeled VPSGHBOOT or similar on the slave HDD (hard drive T) along with a large section of unallocated space that did not show before. DO NOT DELETE VPSGHBOOT yet.
What probably happens here is: ghost creates a special file, or at least writes to an empty part of your filesystem. Then, it writes a complete mini-os to this 8 MB region.
It backs up the original MBR (which is the bootsector, it also hold the partition table) and writes its own MBR. This MBR has a partition table which includes an 8 MB partion. The boundaries of the partition are the boundaries of the special file.
Since this MBR isn't meant to be used in any normal operation environment, it's not quite legal. Some (not all, the MBR can only hold 4) of the original partitions still show up in the new MBR. Therefore, the 8 MB partition lies inside a much larger partition.
This probably confuses fdisk, which lets you create a partition directly after the 8 MB partition, but inside your original partition.
When you subsequently delete the 8 MB partition, fdisk is probably confused again. The end of the original partition is probably obscured by the new, overlapping partition. So it lets you create yet another partition, from the beginning of the disk to the start of the overlapping partition.
The end result is: one large partition holding two small partitions inside it. This will exactly double your diskspace. Just don't try to use it:-)
Slashdot Mirror
The problem is that the amount of data on our disks keeps growing and growing, while our tools to index and search that data are designed with only small filesystems (like, 40 MB) in mind.
Imagine a filesystem in which you can store your email, and that the filesystem can be made to understand your mail. Want all mails sent by John Doe to you? The filesystem knows the answer.
If your email application is aware of the database driven filesystem, it does not have to implement its own mailstore. Currently the application has to use mbox, maildir, or some other format.
Of course, it doesn't end there. What about the user database, currently stored in /etc/passwd? The format is flawed, proved by the existence of /etc/shadow and setuid tools for mortals to edit them. Why not make a simple password file which only contains the encrypted password which a user can edit?
The possibilities don't end there. All files with some internal structure can be stored in the db-fs.
No more mp3's with a hacked md3 tag in them. Just store the metadata where it belongs: outside the data stream.
A db-fs will dramatically alter the way we work with computers. It truly is the next step in computing. Therefore, it will also take a LOT of time before it is implemented. 10 years at least.
If it's hard to understand what such a system would look like: imagine you store all your data into an SQL database. Yes, that's a lot of change.
Worried about the bloat? Bloat is no problem. First of all, since we won't have a db-fs for another 4 years or so, with widespread acceptance 10 years from now, our computers will be WAY faster than what we're using now. Secondly, a db-fs won't be a full-blown SQL database. The kernel only implements some primitives, while userspace libraries implement the actual logic, the 'meat' of the system. Since kernel memory cannot be swapped out, this matters a lot. Finally, what bloat is today, is necesary tomorrow. Imagine an oracle database on hardware from the seventies. Bloated beyond imagination, dog slow. But since the seventies the amount of data stored in a database has grown tremendiously, to the level where we simply need databases like Oracle or SQL Server to store it. Luckaly, the hardware to run it on has grown to.
No, the only real big obstacle to a db-fs is user ignorance. Or conservatism. People either won't understand its importance, or won't want to change.
Once Longhorn is out, it will take a few years for them to understand what's going on, and OSS is up to chasing taillights once again. Please don't let it come that far and start thinking about db-fs'es now.
Just use a bang path: www!yahoo!com!
The KDE mime database can be found in the control center under KDE Components-> File Associations.
For each mimetype you can add a list of handler applications and a list of embeddable parts, called KParts.
All I/O is handled by the KIO subsystem, which has handlers for about any protocol which can transfer files, including local disk, http, ftp. All KDE applications (and KParts) use the KIO system, so all KDE applications can read and write data from and to all protocols.
The communications protocol is called DCOP, and yes, it's object oriented. Don't know whether it's a bus or a point-to-point protocol though. It's very easy to use though, even from shellscripts.
Docs can be found on developer.kde.org.
What you're describing exists today, and it's called KDE.
The AC doesn't say it can't be done in the gimp. He says it's hard to do in the gimp, taking him more time and therefore costing him productivity.
So please stop pointing out the features in the Gimp, and tell how easy and fast it is using these features.
In my experience, this is exacly the problem in the usability discussion. Most people completely miss the point, saying that after countless tweaks which are very hard to implement for a novice user, the system works just fine.
IMHO, they take the easy way out. Making a system usable by default is hard. Very hard.
Why on earth would you want to learn to do something as uninteresting as installing sound drivers into your OS?
You run your servers with a tiny amount of ram?
Except that .com isn't the first TLD to perform rapid updates. AFAIK .info already does this. So spammers can move sites quickly today. No change in that.
Some people munge their address like me@SPAMhotmail.com. All mail delivered on that domain is spam. check the stats.
So, KDE is built with small parts and tools, they're just very nicely intergrated.
However, I'm supprised that no really bad security holes in konqueror have been discovered yet. Browser and file manager intergrated is very nice, but also very scary...
It's not intergrated with the kernel. It's intergrated with the OS. MSIE is basically a set of libraries used by lots of applications, including msie.exe-the-browser.
You can compare msie intergration into the Windows OS with khtml intergration into KDE. You simply cannot rip khtml out of KDE without breaking a bunch of (critical) applications. Same goes with MSIE.
Yeah, but that's because everybody's linking to that site.
Very few applications are purely CPU based. Most applications wait for the user to decide what he/she wants to do.
The speed of interactive applications is mainly limited by the user operating it. So, the application should aid the user in the process of making descisions.
Part of this aid is making the application less suprising. Should a sidebar pop up at the left side of a window as quickly as possible, or should it 'slide' in in a few tens of a second? The slide does grab the user's attention, which could lead to an overall speedup in the work actually done by the user.
This Sun desktop may also aid the user. The user is working more efficiently at the expense of CPU cycles. But hey, isn't that exacly what computing is about?
And that's exactly why assembly is mostly irrelevant (with a few exceptions, of course).
Assembly is faster than C only if you have a lot of time to spare. And C is faster than [your favorite higher lever language here] only if you have lots and lots of time to spare.
The problem is: there is no REALLY good high level language for generic application development (things like word processors, web browsers, etc). However, a language like C# could become such a thing.
I think that in a few years time only the time critical parts of an application are written in C and the hardware dependant parts are written in assembly. For all the rest there is [insert future high level language here].
Using apt4rpm I just completed a dist-upgrade. I have had a few major problems:
My overall impression of the distro so far is that it's suse 9.0, but slightly better.
There are two kinds of speed: things that are fast and things that feel fast.
The article and the comments here on /. are mainly talking about true benchmarkable speed. Things that are fast.
But some apps don't really need to be fast. They just have to feel fast. This holds true for most interactive applications. It's all about psycholigy with this one.
Ever wondered why Windows Explorer builds up its icons from the right bottom to the top left? Doesn't matter in real speed, but it just feels faster. Your brain just isn't used to this flow: usually you read from the top left to the bottom right, or you read from the top right to the bottom left. Your eyes immediately focus on the spot your brain expects the icons to appear. But instead the appear in the opposite corner. By the time your brain figures out it has been tricked, the window is already full of icons.
More tricks: ever wondered why windows wastes memory by trying to have some free memory ready all the time? It makes starting new apps faster. But on average the system is slower.
In the Unix world there is only raw, benchmarkable speed. And that's why KDE and Gnome are slow. They aren't slow, they just feel slow.
Klipper is nice, but make sure you exclude Firefox from it. Somehow Klipper makes Firefox progressively slower and after a few hours of use firefox just crashes.
Withour Klipper Firefox runs for days without crashes, and fast as ever.
At least in my experience. Your mileage may vary.
I've had a similar problem on my LAN. Large packets would always be corrupted, while small packets would get trough.
Well, it wasn't really a lan. It was two computers with a crosscable between them. The problem: one of the computers is a Duron and the user installed a power-management tool on his computer. The tool put the processor in sleep mode when idle (no, not HLT, but a deeper sleep mode). Problem was: not all old Duron/Athon boards correctly support this sleep mode. The power supply was generating spikes, which were evidentely picked up by the NIC and relayed to the network.
First of all: rpm is both a format an a tool. Both are fine. The format used in debian is deb and the tool used in debian is dpkg. Both are fine too.
Suse's apt-get equivalent is yast. But if you don't like yast, just install apt.
Second: yast md5sums all your configfiles and refuses to overwrite any modified files:
So what's your problem with suse again?
Sure, and both Linux 2.4 and 2.6 do caching and read-ahead (reading more data than requested, hoping that the application will request the data in the future).
The I/O scheduler however lies beneath the cache layer. When it's decided that data must be read from or written to disk, the request is placed in a queue. The scheduler may reorder the queue in order to minimize head movements.
Also, 2.6 has the anticipatory I/O scheduler: after a read, the scheduler simply pauses for a (very) short period. This is done in the assumption that the application will request more data from the same general area on the disk. Even when other requests are in the I/O queue, requests to the area where the disk's heads are hovering will get priority.
While this increases latency (the time it takes for a request to be processed) a bit, throughput (the amount of data transfered in a time period) will also increase.
It did take a fair amount of experimenting and tuning in order to make the I/O scheduler work as well as it does now. However there still may be some corner cases where the new scheduler is much slower than the old.
CSS makes pages more accessible from lynx. So, yes.
It seems to be confusing that one can buy a commercial version of Qt. That version however is extra. If you don't want it, just stick to plain old GPL'ed Qt.
MySQL is doing something similar. Nobody seems to be confused by that one though.
I have to agree. C is not suitable for general application development any more. 'back in the day' we were forced to use C because of performance reasons, but now computers have more than enough horsepower to run higher-level languages smoothly.
You can already see this with web applications: almost nobody writes them in C. They use PHP or Perl. There languages are just far better suited for web development than C.
It may well be that Mono/C# is becoming more suited for general application development than C. Or maybe Python. Or Perl.
I think that in the not-so-distant future C will only be used at places where performance really counts, hidden deep away in libraries and the operating system.
The advantage of replacing C with a higher level language: programmers will be able to concentrate more on the application they're writing and less on the low-level things like coding linked lists, hash tables, etc. This will improve the quality of the applications. Or make applications more complex with constant quality.
An advantage of C#: developers will be able to distribute just one binary version of their application, it'll run on any platform. Not very important in the world of Open Source, but still a nice thing to have.
What probably happens here is: ghost creates a special file, or at least writes to an empty part of your filesystem. Then, it writes a complete mini-os to this 8 MB region.
It backs up the original MBR (which is the bootsector, it also hold the partition table) and writes its own MBR. This MBR has a partition table which includes an 8 MB partion. The boundaries of the partition are the boundaries of the special file.
Since this MBR isn't meant to be used in any normal operation environment, it's not quite legal. Some (not all, the MBR can only hold 4) of the original partitions still show up in the new MBR. Therefore, the 8 MB partition lies inside a much larger partition.
This probably confuses fdisk, which lets you create a partition directly after the 8 MB partition, but inside your original partition.
When you subsequently delete the 8 MB partition, fdisk is probably confused again. The end of the original partition is probably obscured by the new, overlapping partition. So it lets you create yet another partition, from the beginning of the disk to the start of the overlapping partition.
The end result is: one large partition holding two small partitions inside it. This will exactly double your diskspace. Just don't try to use it :-)