Any language where white space is important to determining the blocking structure (e.g. Make leaps to mind) is badly broken. You don't want to totally ignore white space (FORTRAN leaps to mind) but you don't want the number of spaces/tabs before a statement to indicate anything significant.
Huh? Why? All programmers indent their code. Those that don't aren't even programmers. Why do programmers indent their code? So that humans are able to read it. Why do programmers place braces? So that the compiler would be able to read it.
Python just lets you indent for the humans and take care of the compiler at the same time.
Also, it makes sure that the way the code looks is synchronized with what it does. while indentation is insignificant to many compilers, it is very significant to the humans readers - causing a discrepency between the program the programmer reads and the one that the compiler reads.
The "It uses whitespace - it sucks" claim about Python is quite weak, unbased and used by rather ignorant people who never really tried using it. Using signficant whitespace for a while - I can say I'll never look back.
Java... now, there's a great language.
I must say I haven't used Java a lot myself, but any language that combines poor performance with static typing is a hybrid of the worst of C++ and Smalltalk (The quote "Java has the simplicity of C++ and the blazing speed of Smalltalk" comes to mind).
Java is overly "pure" about its OO constructs (Everything must be in a class, etc) while being too weak on its functional constructs (No lexical scoping and closure-like code).
Pretty much any Java program narrows down to a much much simpler and smaller Python program.
Offtopic, true. But what's this bias people have for the inferior Perl? More and more people realize that Python is superior in almost every possible way...
I have started a discussion on Debian Devel about this quite a long while ago.
It sure is nice to see that my idea is being implemented...
However, as others mentioned there are quite a few problems with this approach.
One, is that it is very difficult to use make to perform the reverse (shutdown) using the same input data as the boot.
Another problem, one that I had no time to solve, and seems to not be addressed at all by the article, is that running services in parallel also logs things in parallel. Intermixed logs are quite unfriendly to read.
The plan a few of us at Debian Devel devised was a mini-text-window-manager for the output logs, but noone got around to implementing it.
Lastly, the most serious problem with this approach, was legacy support. Inserting this system into Debian, at least, required that all service package maintainers provide extra dependency information about their packages. This problem was the least feasible to solve.
Thus, my little project died then - and seems to now be revived by IBM:)
US is clearly pro israeli. It has always been that way, it will always be that way.
Has it always?
Prior to the amazing achievements of the small Israeli military in 1967, the US was not really supportive of Israel (Other than the UN declaration of 1947). The US even imposed sanctions on Israel in the war of 1956, for violations of agreements.
Only after the world witnessed that Israel is probably here to stay in the 6-day war, did the US become as supportive as it is today.
Try living under occupation by a foreign military for 35 years and they maybe you can make some sort of a judgement. You think living under Israeli occupation is all fun and games? You think widespread poverty, curfews, restrictions of travel, mass arrests, torture, and an occational missile flying into your cities is fun?
As Sharon put it, "its not easy being a Palestinian". Israel has indeed done a terrible thing, when it placed a military regime in the conquered territories between 1967 and 1987. But you must remmember that this was always a response to terrorist attacks that could not otherwise be prevented.
Then, in 1987, the Intifada broke out. About 6 years later, Israel signed the Oslo peace agreements, even while buses full of men, women and children were exploding. Then, during a tense point in the peace talks - another intifada broke out. This was not justified, and is the main reason why the Palestinians are mostly to blame in this recent conflict.
Also, Lisp is dynamic typed so you can pass whatever you like into a function. Including other functions, lists, symbols, strings, continuations and, eventually with dialects like Arc, macros.
Yes, Lisp is like Python dynamically typed.
However, Lisp is not polymoprhic about its basic types. No Lisp object can be a first-class List in the sense a List can, because no Lisp object can implement the car/cdr protocol.
Give a Lisp function that expects a list some other object, and (car object) will fail.
In Python, "everything is an object", and what that really means is that all access to all program entities is indirected. Sure, this has a performence penalty (at least without smart optimizers), but its more flexible and powerful than Lisp's builtin functions such as car/cdr that do not go through such indirection.
As a side note, unlike many other languages, Python wasn't created out of ignorance of Lisp, but out of realization (that you may agree or disagree with) that Lisp's macros are also a bother because learning a language variant before reading the code can be a nuisance.
I know the claim that learning a new macro-defined syntax is just as hard as learning the semantics of the called functions, but this is not at all true - as there are many guarantees and many properties a Python programmer can easily expect of code - even if it calls unknown functions. There is nothing a Lisp programmer can say whatsoever about some Lisp code that contains use of unknown macros.
While I agree that Python is cool, and in many regards better-designed than all existing Lisp variants, there are still things Lisp can do any Python cannot. (Probably some things going for Ocaml too, but I don't really know it well).
Lisp's main powerful feature is macros, which allows the definition of new syntax. This allows programmers to create a language on top of Lisp to suit their more specific needs.
Python is more powerful than Lisp in many of its semantics, and thus requires less macros to achieve most of its goals. However, no language will ever be complete and ideal for all tasks at hand, and thus macros get you as close as possible to that.
The Founding Fathers did not just come up with copyright as a "great idea" to increase innovation. They did so as a solution to some common problems of those days.
The first problem was publishing of books. Few could afford to distribute information (publishers), and it was not worthwhile to publish a book, if all the competing publishers could just sell the same book as well. This is the well known problem, and not really relevant these days - when distribution of information is a non-issue.
Another problem copyright solved is still relevant today. At the time, there was a profession of very hard and lengthy work - that of drawing maps. Map Makers worked for long periods of times to create accurate maps of many regions. Such boring and expensive tasks would only be done well for a promise of profit.
What map makers did - was sign NDA's and sell their maps under them. This meant that the spread of information was limited, never went public and inspired no new works.
Thus, copyright was created as a protected way to distribute information more openly. Its actually the openness and extra usability of copyrighted information that was so great at the time.
These days, copyrights have deteriorated into laws that are almost as bad as NDA'd distribution of information for map-like (software) products, and much worse for every-day information (books, etc.)
In summary, my point is that if you cancel copyright, the spread of information will be again limited by NDA's (you won't really outlaw those, will you?) rather than copyright. In the case of good copyright laws, this is much, much worse.
Is it rediculous to label numbers that are difficult to come up with as exclusively-distributable by a single entity?
Especially given that the entity can simply sell this number to other entities under NDA's, which is much worse than copyrighted distribution (that later becomes public domain, that is)?
When will File Systems become optional user databases above Orthogonal Persistent storages, which are much easier to implement efficiently, and form a much more convinient platform to work on?:)
The C API docs stink. There's not a single complete example in the doc tree (on python.org) that I've found -- just snippets here and there. There are references that extending Python is very simple (and, indeed, it does appear to be now that I've found sufficient docs) and there's even tools to automate most of it. But nowhere are the actual tools referenced/linked to, there are calls used without explanation or links to explanation, and the docs suddenly shift between extending and embedding without adequate differentiation.
You can find C extension examples in the Python source code (Modules/xxmodule.c, Modules/xxtype.c, etc.).
Also, you might find writing extension Python modules much easier with Pyrex.
This is a superset of Python that compiles down to C code, that compiles to extension modules.
Its a very neat language, and makes C extensions very easy and useful.
The disadvantages over using C directly that I see (I have by no means used Pyrex extensively):
Python object calls will be less efficient than extension C code. For example, calling my_list.append in Pyrex, where my_list is a Python object, will look up "append" in the object's dictionary in runtime, where a human programmer would use PyList_Append() avoiding the lookup.
It may require a bit of work duplication, requiring Pyrex declarations that duplicate existing header files of C functions and types you want to use.
When something is virtually infinitely available (low-cost copying / file sending and sharing), then the free market value of it approaches 0 (The prices of vegetables during the great depression for example, where there were so many in the market their price dropped below the cost of shipping - resulting in mass destruction of produce).
When the value is monopolistically/artifically (via law) set to non-zero - this means that not everyone will afford to get it, and it is assigned the value of a scarcer resource than it is physically. This is artificial scarcity.
It should be called GNU because GNU is the main contributor of operating code. If you want, you can add names of other sub-projects, but since GNU is the most significant part, GNU is the only valid single-name.
Why would I want to use Java, except for writing web applets, when I can use Python+Pyrex, Jython, or other more powerful and more expressive languages?
but EROS does deal with files and file systems - they haven't been thrown away.
EROS the kernel does not deal with files. The base services that I know do not deal with files either. A file may easily be implemented as a collection of page objects, however if you know of a base EROS service that implements "files", please explain what it is, I'll be happy to learn more about EROS features.
That's the whole *point* of EROS.
I wouldn't say that's the whole point of EROS. EROS is more of a capability-system than an orthogonal-persistency system if you ask me. It wouldn't be much of a capability system had it not been orthogonally persistent though.
I think this paragraph from one of the EROS introductory essays gives a more balanced, less gushing, view of its abilities:...
Please explain how this paragraph contradicts anything I said.
Orthogonal Persistence = leave machine on indefinitely. What happens when errors and/or data corruption occur in core? Planned maintenance involving powering down the machine? How about persistent storage (backups, data transference, system upgrades)? And cost: do you think its cheaper to get a 64-bit machine and 500GB of ram to store EROS processes indefinately or a 32-bit machine with 1GB of ram and 500TB of disk space? The whole reason computer systems developed secondary storage is to address these concerns. I get the feeling you think of something else and not Orthogonal Persistency. Orthogonal Persistency does persist the entire state to secondary storage - and you do not need 500GB of RAM, but you can use the same setup you use for conventional systems, even more efficiently.
The question of corruption is a good one - and a frequent one as well. Since the entire state persists indefinitely, what happens if it is corrupted? Then surely the corruption will persist as well. This is true for some types of rare corruption (lower-level persisted kernel-related data structures and other low-level data), but relatively easily solvable for other types of data.
If you examine what happens when the same happens on a traditional system (corruption of the system state), it is generally solved as you imply, by rebooting the machine. The reboot process is a non-selective restart of many components - that fixes the problem.
In EROS, more-selective restarting is done. If a process is corrupted, it is selectively restarted. In reality, data-container processes are simple enough to not corrupt, and even if they do, restarting mechanisms that preserve the data can be used in such processes.
Basically turn everything into memory mappings...and that limits your data size to your address sizes. May not be a problem with 64-bit addressing, but storage is growing exponentially. There is indeed a problem of a limited address space - which is one of the reasons EROS lets you dynamically map your page tables. Also, different processes need not share an address space.
Since typical processes don't handle more than about 2GB of data, they won't need to change their address space mappings. The exceptional applications that need that much storage will have to explicitly (or implicitly via higher-level languages/libraries) remap their address space to refer to other disk pages.
Modern filesystem already make such optimizations as do databases. Heard of LFS? This is a filesystem designed to do this for *BSD. This sounds interesting. However, it is inherent in the approach of traditional file systems that access to files is explicit - and disk sync points are relatively frequent. This means that the disk head must jump around quite a lot.
On the other hand, efficient implementations of Orthogonal Persistency just "sweep through" the entire disk while committing checkpoints writing all of the data in huge bulks. The nature of hard disks makes this approach very efficient, especially since checkpoints accumulate writes from a long period (such as 5 minutes), and since all "swap" writes during this period are done to a relatively small area on the disk without much head movement.
How can LFS avoid the disk head moves and still provide some sort of sane disk synchronization period as well as data coherency?
And backups? Seperating data from instructions? Sharing data across heteregeguous systems? Or is the plan EROS everywhere?
In Orthogonal Persistency systems - backups are actually quite powerful. In fact, the predacessor of EROS (KeyKOS) supported tape backups during checkpoints - that checkpointed not only to the disk but also to a separate tape.
This meant that you could roll back to any checkpoint in history! Quite a powerful backup capability.
As for non-relative backups - that's easily feasible as well, although I do not think anything of the sort is currently implemented.
Relational databases are better than conventional file systems in both performance and transaction management/journalling.
However, the best solution is that used by EROS, which is for the kernel not to provide a file system at all, but instead provide Orthogonal Persistence.
This is a much simpler layer for applications, since it doesn't require them to explicitly access the memory and disk separately. It is also much simpler to recover from because the entire state of the whole disk is always known to be coherent with itself at all given points in time, without an expensive journal.
In terms of performance - it beats the hell out of explicit disk access systems (Both conventional and database systems) because it performs big continuous reads and writes (that don't move the head much) rather than small writes on metadata and file data that forcibly jump the disk head around.
In EROS then, on top of the Orthogonal Persistence, you can create any arbitrary Objects you want easily - because they're just normal processes with normal memory. Conventional File Systems become useless and objects implemented by processes become a much better and more powerful alternative to files.
A relational database of the user objects is then much more powerful than a string hierarchy, but this is all the user's choice - and not hardcoded into a kernel.
When you have enough money to discard any fine? When you have enough power to force any business entity to do almost anything you need? When the authorities of the law are so weak and limited in their power?
The only way to get Microsoft, as well as many other unethical, illegal and otherwise misbehaving companies to obey the law is to gradually increase the punishments given when they are found guilty.
The "corporate death penalty" (the destruction of a corporation and the auctioning of all of its assets) was and still is a possible punishment that can threaten those corporations who show contempt for the law and repeatedly defy it.
The "corporate death penalty" brought, and could bring today - respect of the law.
Call to restore the "corporate death penalty" today!
Slashdot Mirror
Any language where white space is important to determining the blocking structure (e.g. Make leaps to mind) is badly broken. You don't want to totally ignore white space (FORTRAN leaps to mind) but you don't want the number of spaces/tabs before a statement to indicate anything significant.
... now, there's a great language.
Huh? Why?
All programmers indent their code. Those that don't aren't even programmers. Why do programmers indent their code? So that humans are able to read it. Why do programmers place braces? So that the compiler would be able to read it.
Python just lets you indent for the humans and take care of the compiler at the same time.
Also, it makes sure that the way the code looks is synchronized with what it does. while indentation is insignificant to many compilers, it is very significant to the humans readers - causing a discrepency between the program the programmer reads and the one that the compiler reads.
The "It uses whitespace - it sucks" claim about Python is quite weak, unbased and used by rather ignorant people who never really tried using it. Using signficant whitespace for a while - I can say I'll never look back.
Java
I must say I haven't used Java a lot myself, but any language that combines poor performance with static typing is a hybrid of the worst of C++ and Smalltalk (The quote "Java has the simplicity of C++ and the blazing speed of Smalltalk" comes to mind).
Java is overly "pure" about its OO constructs (Everything must be in a class, etc) while being too weak on its functional constructs (No lexical scoping and closure-like code).
Pretty much any Java program narrows down to a much much simpler and smaller Python program.
Offtopic, true.
But what's this bias people have for the inferior Perl? More and more people realize that Python is superior in almost every possible way...
I have started a discussion on Debian Devel about this quite a long while ago.
:)
It sure is nice to see that my idea is being implemented...
However, as others mentioned there are quite a few problems with this approach.
One, is that it is very difficult to use make to perform the reverse (shutdown) using the same input data as the boot.
Another problem, one that I had no time to solve, and seems to not be addressed at all by the article, is that running services in parallel also logs things in parallel. Intermixed logs are quite unfriendly to read.
The plan a few of us at Debian Devel devised was a mini-text-window-manager for the output logs, but noone got around to implementing it.
Lastly, the most serious problem with this approach, was legacy support. Inserting this system into Debian, at least, required that all service package maintainers provide extra dependency information about their packages. This problem was the least feasible to solve.
Thus, my little project died then - and seems to now be revived by IBM
That would flood Israeli elections with arab votes and terminate the Israeli Democracy, to become another arab state.
What should be done is leaving the territories for the Palestinians to have their own state.
As you can see, this is a very difficult process and continuously thwarted by terrorists.
US is clearly pro israeli. It has always been that way, it will always be that way.
Has it always?
Prior to the amazing achievements of the small Israeli military in 1967, the US was not really supportive of Israel (Other than the UN declaration of 1947). The US even imposed sanctions on Israel in the war of 1956, for violations of agreements.
Only after the world witnessed that Israel is probably here to stay in the 6-day war, did the US become as supportive as it is today.
Try living under occupation by a foreign military for 35 years and they maybe you can make some sort of a judgement. You think living under Israeli occupation is all fun and games? You think widespread poverty, curfews, restrictions of travel, mass arrests, torture, and an occational missile flying into your cities is fun?
As Sharon put it, "its not easy being a Palestinian". Israel has indeed done a terrible thing, when it placed a military regime in the conquered territories between 1967 and 1987. But you must remmember that this was always a response to terrorist attacks that could not otherwise be prevented.
Then, in 1987, the Intifada broke out. About 6 years later, Israel signed the Oslo peace agreements, even while buses full of men, women and children were exploding. Then, during a tense point in the peace talks - another intifada broke out. This was not justified, and is the main reason why the Palestinians are mostly to blame in this recent conflict.
Also, Lisp is dynamic typed so you can pass whatever you like into a function. Including other functions, lists, symbols, strings, continuations and, eventually with dialects like Arc, macros.
Yes, Lisp is like Python dynamically typed.
However, Lisp is not polymoprhic about its basic types. No Lisp object can be a first-class List in the sense a List can, because no Lisp object can implement the car/cdr protocol.
Give a Lisp function that expects a list some other object, and (car object) will fail.
In Python, "everything is an object", and what that really means is that all access to all program entities is indirected. Sure, this has a performence penalty (at least without smart optimizers), but its more flexible and powerful than Lisp's builtin functions such as car/cdr that do not go through such indirection.
As a side note, unlike many other languages, Python wasn't created out of ignorance of Lisp, but out of realization (that you may agree or disagree with) that Lisp's macros are also a bother because learning a language variant before reading the code can be a nuisance.
I know the claim that learning a new macro-defined syntax is just as hard as learning the semantics of the called functions, but this is not at all true - as there are many guarantees and many properties a Python programmer can easily expect of code - even if it calls unknown functions. There is nothing a Lisp programmer can say whatsoever about some Lisp code that contains use of unknown macros.
While I agree that Python is cool, and in many regards better-designed than all existing Lisp variants, there are still things Lisp can do any Python cannot. (Probably some things going for Ocaml too, but I don't really know it well).
Lisp's main powerful feature is macros, which allows the definition of new syntax. This allows programmers to create a language on top of Lisp to suit their more specific needs.
Python is more powerful than Lisp in many of its semantics, and thus requires less macros to achieve most of its goals. However, no language will ever be complete and ideal for all tasks at hand, and thus macros get you as close as possible to that.
Isn't KDE quite configurable about its look&feel?
You can change the fonts, styles, colors, click behaviour, widget themes, sounds, menus, panel and desktop.
I don't see why they couldn't simply use a configured KDE setup if they wanted a difference from Windows.
No, if they install more Linux machines they have to pay for licenses from the SCO Group. :)
The Founding Fathers did not just come up with copyright as a "great idea" to increase innovation. They did so as a solution to some common problems of those days.
The first problem was publishing of books. Few could afford to distribute information (publishers), and it was not worthwhile to publish a book, if all the competing publishers could just sell the same book as well.
This is the well known problem, and not really relevant these days - when distribution of information is a non-issue.
Another problem copyright solved is still relevant today. At the time, there was a profession of very hard and lengthy work - that of drawing maps. Map Makers worked for long periods of times to create accurate maps of many regions. Such boring and expensive tasks would only be done well for a promise of profit.
What map makers did - was sign NDA's and sell their maps under them. This meant that the spread of information was limited, never went public and inspired no new works.
Thus, copyright was created as a protected way to distribute information more openly. Its actually the openness and extra usability of copyrighted information that was so great at the time.
These days, copyrights have deteriorated into laws that are almost as bad as NDA'd distribution of information for map-like (software) products, and much worse for every-day information (books, etc.)
In summary, my point is that if you cancel copyright, the spread of information will be again limited by NDA's (you won't really outlaw those, will you?) rather than copyright. In the case of good copyright laws, this is much, much worse.
Is it rediculous to label numbers that are difficult to come up with as exclusively-distributable by a single entity?
Especially given that the entity can simply sell this number to other entities under NDA's, which is much worse than copyrighted distribution (that later becomes public domain, that is)?
If you care more about safety than performance, why do you use C at all?
When will File Systems become optional user databases above Orthogonal Persistent storages, which are much easier to implement efficiently, and form a much more convinient platform to work on? :)
You can find C extension examples in the Python source code (Modules/xxmodule.c, Modules/xxtype.c, etc.).
Also, you might find writing extension Python modules much easier with Pyrex.
This is a superset of Python that compiles down to C code, that compiles to extension modules.
Its a very neat language, and makes C extensions very easy and useful.
The disadvantages over using C directly that I see (I have by no means used Pyrex extensively):
Python object calls will be less efficient than extension C code. For example, calling my_list.append in Pyrex, where my_list is a Python object, will look up "append" in the object's dictionary in runtime, where a human programmer would use PyList_Append() avoiding the lookup.
It may require a bit of work duplication, requiring Pyrex declarations that duplicate existing header files of C functions and types you want to use.
Writing C code that works ok, and designing a secure sandbox require different skills.
:)
According to my aquiantance with the Python C code, the first skill is there
As for the other, I am not sure.
You seem to assume post-9/11 security is about prevention of the recurrance of the exact 9/11 events.
That seems silly, as closed cockpit doors, air patrols, etc wouldn't protect you from any other form of terrorist attack.
When something is virtually infinitely available (low-cost copying / file sending and sharing), then the free market value of it approaches 0 (The prices of vegetables during the great depression for example, where there were so many in the market their price dropped below the cost of shipping - resulting in mass destruction of produce).
When the value is monopolistically/artifically (via law) set to non-zero - this means that not everyone will afford to get it, and it is assigned the value of a scarcer resource than it is physically. This is artificial scarcity.
Its a lot more than just GNU, so you can call it:
GNU/Linux/XFree/KDE/etc.
Or, if you choose a single name, choose the most singificant single contributor: GNU.
This is the FSF claim.
It should be called GNU because GNU is the main contributor of operating code.
If you want, you can add names of other sub-projects, but since GNU is the most significant part, GNU is the only valid single-name.
Or at least, that's the FSF claim.
Pyrex compiles down to C Python extensions.
:)
Python is almost the holy grail for me
Its good for everything but performance - which is where Pyrex fills the gap.
Raw C or even Assembly may still be required for extremely rare situations requiring optimization, but otherwise Python suffices.
Java, on the other hand, combines the slowness of dynamic languages, with the difficulty of typical Bondage and Disipline languages.
Why would I want to use Java, except for writing web applets, when I can use Python+Pyrex, Jython, or other more powerful and more expressive languages?
but EROS does deal with files and file systems - they haven't been thrown away.
...
EROS the kernel does not deal with files.
The base services that I know do not deal with files either. A file may easily be implemented as a collection of page objects, however if you know of a base EROS service that implements "files", please explain what it is, I'll be happy to learn more about EROS features.
That's the whole *point* of EROS.
I wouldn't say that's the whole point of EROS. EROS is more of a capability-system than an orthogonal-persistency system if you ask me. It wouldn't be much of a capability system had it not been orthogonally persistent though.
I think this paragraph from one of the EROS introductory essays gives a more balanced, less gushing, view of its abilities:
Please explain how this paragraph contradicts anything I said.
Orthogonal Persistence = leave machine on indefinitely. What happens when errors and/or data corruption occur in core? Planned maintenance involving powering down the machine? How about persistent storage (backups, data transference, system upgrades)? And cost: do you think its cheaper to get a 64-bit machine and 500GB of ram to store EROS processes indefinately or a 32-bit machine with 1GB of ram and 500TB of disk space? The whole reason computer systems developed secondary storage is to address these concerns.
I get the feeling you think of something else and not Orthogonal Persistency.
Orthogonal Persistency does persist the entire state to secondary storage - and you do not need 500GB of RAM, but you can use the same setup you use for conventional systems, even more efficiently.
The question of corruption is a good one - and a frequent one as well. Since the entire state persists indefinitely, what happens if it is corrupted? Then surely the corruption will persist as well.
This is true for some types of rare corruption (lower-level persisted kernel-related data structures and other low-level data), but relatively easily solvable for other types of data.
If you examine what happens when the same happens on a traditional system (corruption of the system state), it is generally solved as you imply, by rebooting the machine. The reboot process is a non-selective restart of many components - that fixes the problem.
In EROS, more-selective restarting is done. If a process is corrupted, it is selectively restarted. In reality, data-container processes are simple enough to not corrupt, and even if they do, restarting mechanisms that preserve the data can be used in such processes.
Basically turn everything into memory mappings...and that limits your data size to your address sizes. May not be a problem with 64-bit addressing, but storage is growing exponentially.
There is indeed a problem of a limited address space - which is one of the reasons EROS lets you dynamically map your page tables. Also, different processes need not share an address space.
Since typical processes don't handle more than about 2GB of data, they won't need to change their address space mappings. The exceptional applications that need that much storage will have to explicitly (or implicitly via higher-level languages/libraries) remap their address space to refer to other disk pages.
Modern filesystem already make such optimizations as do databases. Heard of LFS? This is a filesystem designed to do this for *BSD.
This sounds interesting. However, it is inherent in the approach of traditional file systems that access to files is explicit - and disk sync points are relatively frequent. This means that the disk head must jump around quite a lot.
On the other hand, efficient implementations of Orthogonal Persistency just "sweep through" the entire disk while committing checkpoints writing all of the data in huge bulks. The nature of hard disks makes this approach very efficient, especially since checkpoints accumulate writes from a long period (such as 5 minutes), and since all "swap" writes during this period are done to a relatively small area on the disk without much head movement.
How can LFS avoid the disk head moves and still provide some sort of sane disk synchronization period as well as data coherency?
And backups? Seperating data from instructions? Sharing data across heteregeguous systems? Or is the plan EROS everywhere?
In Orthogonal Persistency systems - backups are actually quite powerful. In fact, the predacessor of EROS (KeyKOS) supported tape backups during checkpoints - that checkpointed not only to the disk but also to a separate tape.
This meant that you could roll back to any checkpoint in history! Quite a powerful backup capability.
As for non-relative backups - that's easily feasible as well, although I do not think anything of the sort is currently implemented.
I do
Relational databases are better than conventional file systems in both performance and transaction management/journalling.
However, the best solution is that used by EROS, which is for the kernel not to provide a file system at all, but instead provide Orthogonal Persistence.
This is a much simpler layer for applications, since it doesn't require them to explicitly access the memory and disk separately. It is also much simpler to recover from because the entire state of the whole disk is always known to be coherent with itself at all given points in time, without an expensive journal.
In terms of performance - it beats the hell out of explicit disk access systems (Both conventional and database systems) because it performs big continuous reads and writes (that don't move the head much) rather than small writes on metadata and file data that forcibly jump the disk head around.
In EROS then, on top of the Orthogonal Persistence, you can create any arbitrary Objects you want easily - because they're just normal processes with normal memory. Conventional File Systems become useless and objects implemented by processes become a much better and more powerful alternative to files.
A relational database of the user objects is then much more powerful than a string hierarchy, but this is all the user's choice - and not hardcoded into a kernel.
When you have enough money to discard any fine?
When you have enough power to force any business entity to do almost anything you need?
When the authorities of the law are so weak and limited in their power?
The only way to get Microsoft, as well as many other unethical, illegal and otherwise misbehaving companies to obey the law is to gradually increase the punishments given when they are found guilty.
The "corporate death penalty" (the destruction of a corporation and the auctioning of all of its assets) was and still is a possible punishment that can threaten those corporations who show contempt for the law and repeatedly defy it.
The "corporate death penalty" brought, and could bring today - respect of the law.
Call to restore the "corporate death penalty" today!