I might be wrong and you're a troll. But if you're not:
You sir, are a new low in Slashdot, which is quite an achievement.
Completely ignoring the facts of the case - that the BSD folks infringed on the GPL, got a polite notice with an offer of assistance, and instead of apologizing, got angry and started flaming the GPL-code authors.
A lowly ad-hominem attack on an organization that has little to do with the case in the story.
Spewing baseless shit about trying to kill the BSD project.
Absurd referral to the FSF as some control-freak organization, as if the FSF has control over anything more than the GNU project and code - which was mainly written by the FSF itself.
Congratulations! You can claim your New Slashdot Low prize at a Slashdot store near you.
There are apparent moral inconsistencies but not where you were looking.
I am against copying without permission of open-source code, but I have no moral problem with copying of closed-source software, for example.
The reason is that my objection is not because of copyright law being infringed on, but because I believe software should morally be free and copyrights should not apply to private individuals.
In an ideal world, from my perspective, copyright law would not apply to private individuals, and open-source code fits that. Closed-source software (or copyrighted-against-private-individuals music, as in your example) in itself is a great moral violation - and distributing it freely (even though it is illegal) is thus no problem - and even mitigates some of the moral problem of the copyright itself.
I hope that clears up the apparent inconsistency with regard to copyright law.
Eating with your mouth open is legal, while relicensing others' code and plagiarism (esp. as it violates the GPL) is not.
To say that a public notice of such illegal act (that also happens to violate the notifier, unlike eating with an open mouth) is not legitimate - is just absurd. While it may not be an act to expect between two best friends, it is socially acceptable. Not only that, but this notice was not exaggerated, was only claiming facts (and not making blatant emotional accusations), and suggested to help with relicensing. Compare this with another legitimate response - of issuing a cease and desist legal letter, and you see that the notifier here was being very generous. I may not have expected that kind of mail between two best friends, but to say that it is inhuman or otherwise not legitimate is a gross exaggeration. This issue would need to become public anyway - in order to ensure people do not use the relicensed GPL code.
To even imply that the forum being too wide is worthy of discussion when the larger issue of GPL infringement is at hand is also absurd.
Are you a troll? Minix wasn't free - it was the primary incentive for Linus to start working on Linux.
ironically enough as it architecturally started to resemble the Solaris kernel of which Torvalds is so dismissive.
Why do you say Linus is dismissive of Solaris? Because when it went open, he was not interested in researching it? If you are not curious about something - then you are not curious - not dismissive.
When many people are demonstrating, they are basically saying that they are willing to put their time, effort and sweat into the cause - they mean business.
When they sit around in their couch and post stuff in YouTube, they aren't making any point at all. They are just whining.
There is already a P partial solution to the travelling salesman. It does not find the best path, but it is proven that it finds at worst a path that's twice as long. With a few heuristics, the worst case becomes very rare, and it usually finds something closer to the best solution.
So if we solve the NP travelling salesman in a perfect way, at most we'll get paths that are half the length. That could be an improvement, but not a revolution.
I have read it a while ago, and when I have more time I may read it again.
Obviously the article writer is limited to the ideas and possibilities he has been exposed to or thought of, and not to those he haven't. Will write a more detailed response after rereading it thoroughly.
When I looked at doing this (which is almost a decade ago, so bear with me if some details of my memory fail me), I found it was very hard even to define I/O resources. The problem is that you have seeking, reading and writing, spanning several disks and several heads, and with little information being available to help you optimize, and a cache that can make it hard to measure (though I don't know of any filesystem that even try to measure.) Back in the late 70s and early 80s, it was much easier, and filesystems (e.g, UFS) were optimized to deal with the number of heads in use, and setting up cylinder groups that fit with this. These days, there are so many interactions that it seemed like any attempt to schedule would lose large amounts of I/O, as it would easily get in the way of sorting of requests in disk order.
Yes, it is indeed a problem with disk access. If you want to guarantee disk accessibility you have to give up some seeking efficiency. However, I believe that the low-requirement processes that are always starved by the high-requirements ones will only require a tiny bit of disk access, as they can mostly fit in RAM and do not usually span large amounts of memory.
I think maybe you are missing some subtlety here? While the modern VM systems allocate backing store dynamically and use "everything" as cache for disk, the use of serialization lead to a very different access pattern for files and "memory". This is used for prefetching decisions (or at least it used to be used for prefetching decisions, and I assume that makes sense still), and I also seem to remember it being used for handling swap writes compared to file system writes (swap space writes could be done more or less as a Write-Anywhere, as it was losable on power failure, while FS requires more careful updates of metadata).
The different access pattern of a typical program is for startup/shutdown (access to files) and normal operation (access to memory). This leads to the difference you talk about (careful updates of metadata). But if processes always used normal operation and only accessed memory, and a checkpointing system was careful to take snapshots frozen in time, then access to the serialized data (files) would be unnecessary. All of the serialization/de-serialization code could be discarded. Power failures would go back at most a few minutes of whole-computer time. Any process that requires a write-now can still request it from the OS. Typically that would be a database program, in which case a power failure may lead to some of its data being newer than other parts of its data, and it is its responsibility to deal with it. However, this only complicates database and few other programs as most programs don't care for or deal with guaranteeing data survival over computer crashes. Note that with a file system, a crash can already lead to inter-file references' corruption as you are not guaranteed the order of writes to the files, especially when multiple processes are involved.
And we already have the ability to work only with in-memory formats through the use of mmap() and/or coredumping+undump (undump is an utility to make a core dump executable) - it hasn't really taken off much, and I'll discuss why below.
mmap and undump are not equivalent, as they do not allow to work with persistent pointers (You cannot be guaranteed access to certain addresses when you remap the area), they still require handling file-space (opening the files and dealing with that) and in general do not simplify the interface to programs as much as a persistent linear space would.
You didn't take the time to format the next section properly, but I think I managed to exract what you're trying to say. I don't think that:
Managing the program's files (configuration files, as well as persistent data files)
Messing around with various *nix differences in file access
1. I find this reasonable, even though it is fairly complex to implement. The problem is that there isn't one resource to schedule - there are a lot of different ones that interact. The primary problem, as I see it, is the I/O capacity isn't scheduled, while CPU is. Historically, CPU was the really scarce resource. These days, memory and IO capacity is what is scarce, while CPU is generally cheap. (There are also some problems related to X windows being an application and out of memory conditions, these can be dealt with through an application hierarchy.)
I agree it is hard. If it was easy it would probably have been done already by Linux and Windows. But I don't believe it is very hard - as allocating I/O and RAM resources in a prioritized way is not that difficult.
2. There ARE multiple types of memory, and they behave differently. There is an 100,000 times difference in access speed between RAM and disk. For reasonable performance/stability, there is a need to distinguish these to a larger degree than is presently done. Some data structures need to be fast, some are fine with being swapped to disk, and quite a few are just cache and can be recomputed at will. It is fairly common to have caches that we are better off throwing out and recomputing when necessary than we are swapping them out and in again; this should be possible to specify. That's part one of my reason for disliking your idea.
I think you have not understood the comparison I made to existing OS's. They already lie to you about the memory that they are allocating, and there is no way for you to actually allocate RAM or disk, as the OS will just change it at will. Since RAM and disk are already inter-changable from the app's point of view, it will be no degradation to simply expose only one memory allocation system. It is a mere simplification of today's model - not a real change of policy. As for not swapping in/out calculations - I agree and I thought it was my unique idea but I guess others have thought of it as well:-) Allowing for special re-calculate-able memory to be allocated (which is thrown away instead of thrown to disk) is a good idea, but does not contradict exposing a simple linear space to programs instead of both that and a file-space.
Part two is that you go for much higher state dependence, and much less testability than presently. Serializing and re-loading reset the state of programs; this means that corruption is short lived. Not doing this can easily lead to extremely complex bugs, and extremely complex working conditions.
If you consider that a considerable part of today's programs' complexity is in serializing/de-serializing their data, as well as a considerable amount of runtime in startup/shutdown, the question becomes whether having the serialized form of the data which might be more easily testable is worth it. If it is worth it, it can still be done in a more simple way in a persistent system - and can be done away with in many programs that don't face corruption problems. Also safe languages are slowly taking over the world, which makes the more difficult corruption types (pointer/memory management) go away, and thus make corruption easily tracable to a module.
3. Network transparency: Computers fail as a unit. Networks fail partially. These make network transparency a fake dream: The network isn't transparent.
I believe this to be a fallacy. The entities in the computing world are threads and processes, not computers. entities fail, not computers. There are various reasons that a thread or process you are talking to can fail, and all of these are encapsulated in possible failures of API's and such. Computers or links failing expose the exact same problem (from the API user's point of view) and should thus not be treated differently. The network is just as transparent as an in-computer link.
You can create a fully persistent system using today's RAM and disk space, by using RAM as a cache to disk-space.
You'll get the RAM performance like you do today (today RAM is caching file-space, and used for malloc/sbrk space - in a persistent system it will be used to access MRU disk pages). But: You'll get much better disk performance as data will be thrown to disk not in random file writes, but in periodic checkpoints - in which a gathering of minutes of writes is written all at once, utilizing the disk heads much more efficiently.
What you are saying is that my Slashdot post was not the first to expose these ideas.
I know that:-)
Orthogonal Persistency and Capability Systems should become the norm and mainstream, and that's basically what I'm saying (along with a few other things).
It does sound nice, I shall try OS/400 at one point if it becomes free software (if only for the persistent space).
How does the OS/400 security model work? Is it ACL based? If so (it probably is, as that's the mainstream model) it means that the security failures I mentioned above still exist with it.
I would not propose an "always persistent" memory, because too many calculations are temporary
These temporary calculations are already persisted in many cases into the swap area. If they are overwritten in RAM before going to swap, they would be overwritten in RAM before being persisted by a checkpoint in an all-persistent system as well.
Everything-is-persistent does not mean that every write to RAM is a write to disk, that is a naive outlook. It only means that:
the model exposed to programs is simpler (64-bit or 128-bit memory space, rather than a 64-bit memory space + open/read/write file-space)
after a crash you have a guarantee that all data comes from the same chronological point
the disk can be utilized far better because data is written back to the disk in a sweep which utilizes the disk heads more efficiently
1) How do you know a GUI application from a non-GUI one? What about programs that are run locally, but viewed remotely, and vice versa? What constitutes a "GUI" application?
I said User Interface, not a GUI. At first, I'd start by making the mouse, buttons, widgets, and definitely the or a task manager be completely responsive under any load conditions.
Secondly, I would always prioritize low-demanding processes over high-demanding ones, so that if a process wants just 1% of the system's resources, it will get them even if another one is trying for 100%. This would make almost all processes (which really do well with just a few percentages of the resources) be responsive under all conditions.
2) But you are allocating different types of "memory"! See Leaky Abstractions for more information on this. Your "everything is memory" model sounds nice, but lacks a few key components.... When I fclose() a file, I have a STRONG assurance that the file has been saved and wouldn't go away if the power failed. That's not the case in your "everything is memory" model...
When you fclose() a file, your assurance that the file has been saved, is fake, because the disk controller does not even guarantee it will write the data when the OS sends it to it, and there are multiple caches on the way (except the OS one). In my "everything is memory" model, I can still ask the OS to "please get this data written to disk asap". In fact, when you work with files, you have no guarantee about the order of writes, and if a crash occurs, there is no chronological guarantee that the files aren't corrupt with regards to cross-references between the files. In a persistent model, I have a guarantee that after a crash, everything will at least be from the exact same chronological point and so cross references are not corrupt.
3) You are either talking about a security nightmare or pixie dust. How does computer B know that it's OK to run code from computer A? See other comments on #4
Running code, unlike what a lot of people think, is harmless (at least since the F00F bug was resolved) and there are no known CPU bugs that allow the mere running of code to be dangerous. What's dangerous is allowing the running code to ask a lot of requests from a lot of entities which may expose bugs in the many many handlers of these requests in the many entities, or in one of the many ACL lists maintained by the system. In a capability model, the code you are running has only one channel through which to ask requests, by activating a capability. If the code is given no capabilities, it is harmless. If it is given a capability to display in a window, it may only harm that window, and at worst it may take over the code that runs that window and access the few more capabilities it has (which would be access to the screen as a whole, and not much more than that).
By the way, as part of the Programming Languages part, I believe that in the future, only safe languages should be used, so that we don't need CPU protection mechanisms and this would be a further guarantee that there's no problem running safe-language code from an untrusted entity.
4) Capability security requires somebody to set up all those !#@!@# permissions. POSIX, by contrast, is very simple and requires little effort to maintain. Is POSIX ideal in all situations? No. But it's adequate in most circumstances without a lot of effort, and it's usually better to have a "just barely suits" possibility with a decent default than a perfect possibility with a lousy default. Perhaps that explains why your touted EROS operating system died on the vine?
EROS didn't "die" because it never lived. It was a research project and ended as the research completed, to make way for a new research project by its project manager. It was never meant to become the next Linux or so, so its fate is not a good measure of how capabilities do.
There is no serious overhead to persisting all memory.
EROS proved this by benchmarking much higher performance than Linux and Windows w.r.t to all kinds of persistency.
You say clearing RAM is desirable, when what you actually mean is that restarting a faulty program is desirable - That is possible without rebooting the entire machine, and has nothing to do with persistency.
Your claim about passwords is simply wrong, because making everything persistent will not change what goes to disk (as passwords will already be swapped to disk and persist there), it will just mean that the swap area and file-space are not exposed as 2 differing interfaces to programs.
If you want to avoid the password being written to disk, you can't actually do that in current OS's and you can add a feature to do that in either a persistent system and a current OS.
The software world is in a very poor state indeed.
I think that once someone improves the situation of software architecture and programming languages so that programmers don't have to mess with ad-hoc hacks but instead write the logic that they want to implement, then software will cease to suck.
The main problem is Operating Systems architecture and Programming Languages. Due to lack of time, I will only list a few of the Operating Systems problems that weren't solved after more than 30 years of OS development:
Don't allocate resources sanely. One program (even worse when it has many threads) that is wanting more memory and more CPU will get the entire User Interface to a halt, even though guaranteeing the required resources for a smooth UI is so cheap. (i.e: Instead of guaranteeing 0.5% of the memory/cpu to the UI so its always smooth, even this 0.5% goes as an extra 0.5% boost to the program that's already got 99.4%)
Offer an unnecessarily(historically) complicated model to programs, where there are multiple spaces of memory (malloc'able/sbrk memory, and file system space), even though these memory types are actually interchangable and when you malloc, your RAM is moved to disk, and when you use a file, it often allocated RAM. Instead, operating systems should just expose one type of memory, that is always non-volatile and persistent, so that programs don't have to worry about converting/serializing back and forth between these memory types. This would also get rid of the unnecessary bootup/shutdown sequence all programs are currently dealing with.
Does not offer a high-level world of network-transparent primitives, that allows all method calls to transparently run over a network. If this existed, we would not see the abomination that is web-forms+AJAX and the rest of this ultra-complicated world that still does not work nearly as well as local GUI's. Instead of extending the web to support GUI functionality (poorly), we should have seen GUI's be extended to transparently reach over the network. The X protocol is similar, but not good enough as it transmits too low-level primitives (pixel data and mouse movements) and is also an alternative and not a standard GUI API that the operating system offers.
The security model, using users, groups and assigning those to objects is of very rough granulity, requires a system administrator to modify the model (users/groups) and does not allow fine-grained control over the access of entities (processes) to objects (i.e: As a non-administrator, I cannot prevent my mp3 player from accessing the network or deleting the files it can read). Instead, a capability-security model should be used (not POSIX capabilities, but EROS/KeyKos type ones), which is much simpler to use, verify and much more powerful and fine-grained. This would also facilitate secure movement of components between computers - which could be done automatically by the OS to improve performance. More on that on a later post.
My roommate got the Mac, and I have to say that I was highly disappointed at using it.
It is just as slow, crashy, inconvinient and annoying as the rest (With a few less annoying "update me" popups than Windows, perhaps).
Expose is cool, and the smooth movements of some appearing windows (rather than a one-frame screen-update) is also nice. But these are the only 2 serious improvements I've seen. Things are still very slow to launch, programs crash, and things fail for configuration reasons.
It doesn't have any easy and useful way of exposing available keyboard shortcuts (as in KDE's readily available shortcut settings dialogs, Emacs's show-keybindings command, etc).
For people with a background of both Windows and KDE, who had no troubles with either or with Gnome/etc, it is still very difficult to figure out how to make shortcuts to applications, copy files (rather than make shortcuts), etc.
All in all, the Mac is yet-another-lousy-GUI, in my opinion.
Disclaimer: I'm a KDE fan [though I believe all of today's GUIs, including KDE are very lousy], and not too fond of closed-source applications in general.
As far as I know, JPEG for example, simply transforms the image via matrix multiplication, and then stores with less precision the less important components of the multiplication result.
JPEG 2000 uses a wavelet matrix, which could be simplified and explained as it would operate on a 2-pixel image. Instead of storing 2 pixel values, you can store the average of the 2 pixels, and the difference between the 2 pixels. That is equivalent. Now you can store the average with high precision, and the difference with low-precision. This technique can be used recursively such that the color difference between the upper half of the image and the lower half is stored with low precision, but the average color is preserved well.
This technique preserves the average color of each color zone in the picture pretty well, and loses a bit of resolution in the color difference plane. The human eye tends to notice little difference in the loss of these differences.
Notice that this highly effective JPEG technique is completely disregarding of the actual data in the pixels, so that you gain nothing from compressing after you have the data, and the 1-pixel camera should be able to compress just as well without having the data.
Debian prove time and again that they have spine. They do what's right, according to their policies and to the law -- even when its difficult and non-consensual.
They should be applauded for this.
If some policy has to be changed, its the Firefox name policy.
then it should be my prerogative to decide if I sell that book, if I give it away, who can distribute it...
Why should it? I hope you realize that this is your personal opinion. A lot of us think that the individual freedom to share, copy, modify, or otherwise do anything I want with information in my posesion is more important than the distribution control of the author. This is obviously a tradeoff between certain factors:
The author's control over the distribution (And thus, the profitability and incentive to create works).
The freedom of users to share, copy, or modify the works (And thus, the possibility to enhance the state of the art and a potential to increase efficiency).
The amount of government involvement.
The position people have on copyright is not inherent, and I think you have been educated/conditioned to believe that one thing "should" be and the other shouldn't. I think we "should" decide whether copyright is right/moral based on the perceived value of that tradeoff.
I see where copyright supporters come from, because they simply have different ideas about how important each item in the above list is.
I personally find number 1 and 3 less important, and find number 2 (Both in the freedom and in the efficiency aspect) to be of much higher importance.
That is why I think copyright is wrong.
Copyright is the reason that a popular band cannot claim your work as their own.
Even if that were the case (not having all the facts, I think it is not), a limited law about the ability to make a civilian libel case against those who attribute your work to them would be a satisfactory solution, regardless of copyright.
limited copyrights, like it was originally intended.
Consider also that originally, copyright only applied to publishers, because copying was not practical for individuals.
So you could replace that sentence with one closer to what the pirate party is saying: time-limited copyrights that only apply to for-profit organizations, like it was originally intended.
Disclaimer: This is only about software copyrights, not other types of content
Without hardware support (Treacherous Computing and the likes), it is strictly impossible to make a working system.
The subtle consequence is, that trying to limit distribution in order to gain a profit, where that usually or always fails, will not be profitable.
If its not profitable, then large organizations like Microsoft and others will simply not exist.
If large organizations like those do not exist, then suddenly opensource has got a lot more resources going for them - and the under-funded closed-source organizations which will have far fewer sources of income (than today), will simply not be able to compete with opensource.
Without copyright, we won't see strengthening of copying prevention means, we will see the disappearance of closed software, and thus much more incentive to create opensource will exist (Because a convenient closed alternative will simply not exist).
If no money is in the distribution of software, then suddenly money will be redirected from the buying of software copies (i.e distribution) to money to the software development process directly (i.e hiring a programmer to improve that opensource thing we use). In other words, instead of every software creator in the world rewriting his works from scratch to recreate the state of the art, suddenly people can work on advancing the existing state of the art.
That will substantially increase efficiency and I predict that abolishing software copyrights will speed up software development and increase software freedom by an order of magnitude.
Slashdot Mirror
You sir, are a new low in Slashdot, which is quite an achievement.
Congratulations!
You can claim your New Slashdot Low prize at a Slashdot store near you.
There are apparent moral inconsistencies but not where you were looking.
I am against copying without permission of open-source code, but I have no moral problem with copying of closed-source software, for example.
The reason is that my objection is not because of copyright law being infringed on, but because I believe software should morally be free and copyrights should not apply to private individuals.
In an ideal world, from my perspective, copyright law would not apply to private individuals, and open-source code fits that. Closed-source software (or copyrighted-against-private-individuals music, as in your example) in itself is a great moral violation - and distributing it freely (even though it is illegal) is thus no problem - and even mitigates some of the moral problem of the copyright itself.
I hope that clears up the apparent inconsistency with regard to copyright law.
Eating with your mouth open is legal, while relicensing others' code and plagiarism (esp. as it violates the GPL) is not.
To say that a public notice of such illegal act (that also happens to violate the notifier, unlike eating with an open mouth) is not legitimate - is just absurd. While it may not be an act to expect between two best friends, it is socially acceptable. Not only that, but this notice was not exaggerated, was only claiming facts (and not making blatant emotional accusations), and suggested to help with relicensing. Compare this with another legitimate response - of issuing a cease and desist legal letter, and you see that the notifier here was being very generous.
I may not have expected that kind of mail between two best friends, but to say that it is inhuman or otherwise not legitimate is a gross exaggeration.
This issue would need to become public anyway - in order to ensure people do not use the relicensed GPL code.
To even imply that the forum being too wide is worthy of discussion when the larger issue of GPL infringement is at hand is also absurd.
Are you a troll? Minix wasn't free - it was the primary incentive for Linus to start working on Linux.
Why do you say Linus is dismissive of Solaris? Because when it went open, he was not interested in researching it? If you are not curious about something - then you are not curious - not dismissive.
When many people are demonstrating, they are basically saying that they are willing to put their time, effort and sweat into the cause - they mean business.
When they sit around in their couch and post stuff in YouTube, they aren't making any point at all. They are just whining.
You're right, and I forgot about that, thanks for reminding me.
However, his original wording was "everything from travel to mass transit to shipping", so the triangular relationship holds for my statement.
There is already a P partial solution to the travelling salesman. It does not find the best path, but it is proven that it finds at worst a path that's twice as long.
With a few heuristics, the worst case becomes very rare, and it usually finds something closer to the best solution.
So if we solve the NP travelling salesman in a perfect way, at most we'll get paths that are half the length.
That could be an improvement, but not a revolution.
I have read it a while ago, and when I have more time I may read it again.
Obviously the article writer is limited to the ideas and possibilities he has been exposed to or thought of, and not to those he haven't.
Will write a more detailed response after rereading it thoroughly.
Yes, it is indeed a problem with disk access. If you want to guarantee disk accessibility you have to give up some seeking efficiency. However, I believe that the low-requirement processes that are always starved by the high-requirements ones will only require a tiny bit of disk access, as they can mostly fit in RAM and do not usually span large amounts of memory.
The different access pattern of a typical program is for startup/shutdown (access to files) and normal operation (access to memory). This leads to the difference you talk about (careful updates of metadata). But if processes always used normal operation and only accessed memory, and a checkpointing system was careful to take snapshots frozen in time, then access to the serialized data (files) would be unnecessary. All of the serialization/de-serialization code could be discarded. Power failures would go back at most a few minutes of whole-computer time. Any process that requires a write-now can still request it from the OS. Typically that would be a database program, in which case a power failure may lead to some of its data being newer than other parts of its data, and it is its responsibility to deal with it. However, this only complicates database and few other programs as most programs don't care for or deal with guaranteeing data survival over computer crashes.
Note that with a file system, a crash can already lead to inter-file references' corruption as you are not guaranteed the order of writes to the files, especially when multiple processes are involved.
mmap and undump are not equivalent, as they do not allow to work with persistent pointers (You cannot be guaranteed access to certain addresses when you remap the area), they still require handling file-space (opening the files and dealing with that) and in general do not simplify the interface to programs as much as a persistent linear space would.
You didn't take the time to format the next section properly, but I think I managed to exract what you're trying to say.
I don't think that:
I agree it is hard. If it was easy it would probably have been done already by Linux and Windows. But I don't believe it is very hard - as allocating I/O and RAM resources in a prioritized way is not that difficult.
I think you have not understood the comparison I made to existing OS's. They already lie to you about the memory that they are allocating, and there is no way for you to actually allocate RAM or disk, as the OS will just change it at will. Since RAM and disk are already inter-changable from the app's point of view, it will be no degradation to simply expose only one memory allocation system. It is a mere simplification of today's model - not a real change of policy. :-) Allowing for special re-calculate-able memory to be allocated (which is thrown away instead of thrown to disk) is a good idea, but does not contradict exposing a simple linear space to programs instead of both that and a file-space.
As for not swapping in/out calculations - I agree and I thought it was my unique idea but I guess others have thought of it as well
If you consider that a considerable part of today's programs' complexity is in serializing/de-serializing their data, as well as a considerable amount of runtime in startup/shutdown, the question becomes whether having the serialized form of the data which might be more easily testable is worth it. If it is worth it, it can still be done in a more simple way in a persistent system - and can be done away with in many programs that don't face corruption problems. Also safe languages are slowly taking over the world, which makes the more difficult corruption types (pointer/memory management) go away, and thus make corruption easily tracable to a module.
I believe this to be a fallacy.
The entities in the computing world are threads and processes, not computers. entities fail, not computers. There are various reasons that a thread or process you are talking to can fail, and all of these are encapsulated in possible failures of API's and such. Computers or links failing expose the exact same problem (from the API user's point of view) and should thus not be treated differently.
The network is just as transparent as an in-computer link.
There is no need!
You can create a fully persistent system using today's RAM and disk space, by using RAM as a cache to disk-space.
You'll get the RAM performance like you do today (today RAM is caching file-space, and used for malloc/sbrk space - in a persistent system it will be used to access MRU disk pages).
But: You'll get much better disk performance as data will be thrown to disk not in random file writes, but in periodic checkpoints - in which a gathering of minutes of writes is written all at once, utilizing the disk heads much more efficiently.
What you are saying is that my Slashdot post was not the first to expose these ideas.
:-)
I know that
Orthogonal Persistency and Capability Systems should become the norm and mainstream, and that's basically what I'm saying (along with a few other things).
It does sound nice, I shall try OS/400 at one point if it becomes free software (if only for the persistent space).
How does the OS/400 security model work? Is it ACL based? If so (it probably is, as that's the mainstream model) it means that the security failures I mentioned above still exist with it.
I didn't say it will solve all of our software woes, but it will solve most of them and software will cease to suck.
Everything-is-persistent does not mean that every write to RAM is a write to disk, that is a naive outlook. It only means that:
I said User Interface, not a GUI.
At first, I'd start by making the mouse, buttons, widgets, and definitely the or a task manager be completely responsive under any load conditions.
Secondly, I would always prioritize low-demanding processes over high-demanding ones, so that if a process wants just 1% of the system's resources, it will get them even if another one is trying for 100%. This would make almost all processes (which really do well with just a few percentages of the resources) be responsive under all conditions.
When you fclose() a file, your assurance that the file has been saved, is fake, because the disk controller does not even guarantee it will write the data when the OS sends it to it, and there are multiple caches on the way (except the OS one). In my "everything is memory" model, I can still ask the OS to "please get this data written to disk asap". In fact, when you work with files, you have no guarantee about the order of writes, and if a crash occurs, there is no chronological guarantee that the files aren't corrupt with regards to cross-references between the files. In a persistent model, I have a guarantee that after a crash, everything will at least be from the exact same chronological point and so cross references are not corrupt.
Running code, unlike what a lot of people think, is harmless (at least since the F00F bug was resolved) and there are no known CPU bugs that allow the mere running of code to be dangerous. What's dangerous is allowing the running code to ask a lot of requests from a lot of entities which may expose bugs in the many many handlers of these requests in the many entities, or in one of the many ACL lists maintained by the system. In a capability model, the code you are running has only one channel through which to ask requests, by activating a capability. If the code is given no capabilities, it is harmless. If it is given a capability to display in a window, it may only harm that window, and at worst it may take over the code that runs that window and access the few more capabilities it has (which would be access to the screen as a whole, and not much more than that).
By the way, as part of the Programming Languages part, I believe that in the future, only safe languages should be used, so that we don't need CPU protection mechanisms and this would be a further guarantee that there's no problem running safe-language code from an untrusted entity.
EROS didn't "die" because it never lived. It was a research project and ended as the research completed, to make way for a new research project by its project manager. It was never meant to become the next Linux or so, so its fate is not a good measure of how capabilities do.
Your question of how to s
There is no serious overhead to persisting all memory.
EROS proved this by benchmarking much higher performance than Linux and Windows w.r.t to all kinds of persistency.
You say clearing RAM is desirable, when what you actually mean is that restarting a faulty program is desirable - That is possible without rebooting the entire machine, and has nothing to do with persistency.
Your claim about passwords is simply wrong, because making everything persistent will not change what goes to disk (as passwords will already be swapped to disk and persist there), it will just mean that the swap area and file-space are not exposed as 2 differing interfaces to programs.
If you want to avoid the password being written to disk, you can't actually do that in current OS's and you can add a feature to do that in either a persistent system and a current OS.
I think that once someone improves the situation of software architecture and programming languages so that programmers don't have to mess with ad-hoc hacks but instead write the logic that they want to implement, then software will cease to suck.
The main problem is Operating Systems architecture and Programming Languages.
Due to lack of time, I will only list a few of the Operating Systems problems that weren't solved after more than 30 years of OS development:
This would also get rid of the unnecessary bootup/shutdown sequence all programs are currently dealing with.
Instead, a capability-security model should be used (not POSIX capabilities, but EROS/KeyKos type ones), which is much simpler to use, verify and much more powerful and fine-grained. This would also facilitate secure movement of components between computers - which could be done automatically by the OS to improve performance. More on that on a later post.
My roommate got the Mac, and I have to say that I was highly disappointed at using it.
It is just as slow, crashy, inconvinient and annoying as the rest (With a few less annoying "update me" popups than Windows, perhaps).
Expose is cool, and the smooth movements of some appearing windows (rather than a one-frame screen-update) is also nice. But these are the only 2 serious improvements I've seen. Things are still very slow to launch, programs crash, and things fail for configuration reasons.
It doesn't have any easy and useful way of exposing available keyboard shortcuts (as in KDE's readily available shortcut settings dialogs, Emacs's show-keybindings command, etc).
For people with a background of both Windows and KDE, who had no troubles with either or with Gnome/etc, it is still very difficult to figure out how to make shortcuts to applications, copy files (rather than make shortcuts), etc.
All in all, the Mac is yet-another-lousy-GUI, in my opinion.
Disclaimer: I'm a KDE fan [though I believe all of today's GUIs, including KDE are very lousy], and not too fond of closed-source applications in general.
As far as I know, JPEG for example, simply transforms the image via matrix multiplication, and then stores with less precision the less important components of the multiplication result.
JPEG 2000 uses a wavelet matrix, which could be simplified and explained as it would operate on a 2-pixel image. Instead of storing 2 pixel values, you can store the average of the 2 pixels, and the difference between the 2 pixels. That is equivalent. Now you can store the average with high precision, and the difference with low-precision. This technique can be used recursively such that the color difference between the upper half of the image and the lower half is stored with low precision, but the average color is preserved well.
This technique preserves the average color of each color zone in the picture pretty well, and loses a bit of resolution in the color difference plane. The human eye tends to notice little difference in the loss of these differences.
Notice that this highly effective JPEG technique is completely disregarding of the actual data in the pixels, so that you gain nothing from compressing after you have the data, and the 1-pixel camera should be able to compress just as well without having the data.
Indeed as others said, what is true of tic-tac-toe, is also true of chess (Albeit to a different degree, ofcourse).
Debian prove time and again that they have spine.
They do what's right, according to their policies and to the law -- even when its difficult and non-consensual.
They should be applauded for this.
If some policy has to be changed, its the Firefox name policy.
The position people have on copyright is not inherent, and I think you have been educated/conditioned to believe that one thing "should" be and the other shouldn't. I think we "should" decide whether copyright is right/moral based on the perceived value of that tradeoff.
I see where copyright supporters come from, because they simply have different ideas about how important each item in the above list is.
I personally find number 1 and 3 less important, and find number 2 (Both in the freedom and in the efficiency aspect) to be of much higher importance.
That is why I think copyright is wrong.
Even if that were the case (not having all the facts, I think it is not), a limited law about the ability to make a civilian libel case against those who attribute your work to them would be a satisfactory solution, regardless of copyright.
Consider also that originally, copyright only applied to publishers, because copying was not practical for individuals.
So you could replace that sentence with one closer to what the pirate party is saying:
time-limited copyrights that only apply to for-profit organizations, like it was originally intended.
Disclaimer: This is only about software copyrights, not other types of content
Without hardware support (Treacherous Computing and the likes), it is strictly impossible to make a working system.
The subtle consequence is, that trying to limit distribution in order to gain a profit, where that usually or always fails, will not be profitable.
If its not profitable, then large organizations like Microsoft and others will simply not exist.
If large organizations like those do not exist, then suddenly opensource has got a lot more resources going for them - and the under-funded closed-source organizations which will have far fewer sources of income (than today), will simply not be able to compete with opensource.
Without copyright, we won't see strengthening of copying prevention means, we will see the disappearance of closed software, and thus much more incentive to create opensource will exist (Because a convenient closed alternative will simply not exist).
If no money is in the distribution of software, then suddenly money will be redirected from the buying of software copies (i.e distribution) to money to the software development process directly (i.e hiring a programmer to improve that opensource thing we use). In other words, instead of every software creator in the world rewriting his works from scratch to recreate the state of the art, suddenly people can work on advancing the existing state of the art.
That will substantially increase efficiency and I predict that abolishing software copyrights will speed up software development and increase software freedom by an order of magnitude.