But taxation isn't violent or forceful. Your right to use force resist me taking your money ends where your fist encounters my face. Obviously, there is no right to property.
Property rights exist, no one is denying that, but they are not 'natural' rights; they are granted by the government.
Natural rights, for me, are the right to life, the right to liberty and things extending from that. If you have a right to be alive you have a right to food and shelter, otherwise the right is meaningless. It would be like saying you have liberty but only within this stockade. I don't see any reason why anyone fundamentally needs the right to own things. It's more like a patent, something the government grants at cost to society in hopes of motivating industriousness.
*Fixed* layout is not friendly to different clients, but precise layout is *necessary* for any non-trivial page.
You basically are saying "there is no problem, you're just doing it wrong" -- which is bullshit. Writing web sites that display smoothly across clients and devices is *fiendishly difficult* and it should not be that way. You would not get crappy web sites that look terrible on a cell phone if it weren't too hard to do it the "right way" and still make it look good on a normal screen. The cop-out answer is "make your web pages like simple printed documents on an infinitely long sheet of paper." This is the *official* answer to "CSS doesn't do what we need it to do." But, nobody ever has (or should) listen when told "Do it our way and stop complaining."
Why do you think table-based layouts have been popular for years and are still widely used? It's because CSS doesn't give us a way to do it that actually works (CSS3 notwithstanding since it's still not widely available.)
I can only assume that you, too, have never designed a web site. Don't quote me utopian, textbook answers for how to layout a site. Tell me instead why it should be so hard to tell the client how I want the page to look. There's no reason the standard *couldn't* have a simple way to specify block level alignment, it just doesn't. There's no reason you have to rely on javascript to be able to say "the right edge of the visible page," but you do.
I think the real answer is "You shouldn't have any control over how the user sees your page, not even suggestions. Use HTML to mark up what the content is and leave it at that." CSS was supposed to be for presentation, but it's clear that it was not intended to actually allow control of presentation. In a theoretical world you could get away with just saying "Don't do that," but in the real world we're going to do it because many things are more pleasant that way (and sometimes people pay for it, too.) Since it's going to happen anyway I'd like a spec that actually lets me do it without ripping all my hair out.
I'd like to see a CSS for web developers by web developers, a little like HTML5's attempt to address real problems and not simply to satisfy some theory of good markup structure. But, I am not holding my breath. Even if it were perfect and ready tomorrow I could not rely on it for at least 5 years.
I can only assume you've never written a web page.
CSS was designed by people who never wrote web pages, either. If it had been designed by a web developer there would be a notion of the viewport and a simple way to align content. Floating boxes, 50% negative margins and javascript hacks don't count.
Even if you ignore IE (I've been doing that for years) it's still incredibly complex to precisely lay things out in the browser.
Your definition of troll is specific where it should be non-specific. A troll is someone who says something for the purpose of getting a rise out of the reader, hopefully inspiring a reply, hopefully an angry reply. "3D graphics under Linux suck, this is why I use Windows" is a classic troll in any pro-Linux place (like slashdot!)
You may not have intended it as a troll and may have merely been voicing an opinion, but it certainly reads as inflammatory and certainly looks like a troll. Why didn't you say "I never could get 3D working satisfactorily on Linux, which is why I still use Windows"? This doesn't imply that Linux is deficient and Windows is superior, so it's less likely to read like trolling.
I didn't say it would be easy, but I think it would be inevitable. You can't get such laws passed before the services exist. First you need the services and then you need some horrific company behavior and perhaps a class action lawsuit or two, then you can get the legislation. It wouldn't be possible to do it up front.
It's not especially optimistic and it's not about faith. I think Google will go for it based on their past history but I also think that if they don't people will bail out in droves and go to a competing service. At the moment there aren't really any competitors, but if Google shows how it can be done there will be.
Remember, these guys use XMPP, they have released specs for interoperation left and right. They're likely to do it again with this, sooner or later. Doing it up front is a sure way to see your product die in the alpha stage.
Well, it's logical to Google. To the rest of the world, there are still issues with having your data stored on someone else's platform. What happens if your internet connection drops? What happens if the cloud service provider folds and takes your data with it? What happens if, in a decade's time they are bought out by BigEvilCo who leverage the vendor lock-in implicit in a cloud architecture and hold a decade's worth of your data to ransom?
Step one: Make a computer that operates in the cloud. Step two: Once people are used to this begin selling the *server* or cloud side of the service.
Now Fine Corporation, Ltd. can host its company cloud computers on its company servers using the exact same platform and protocols, just change the domain in the computer's config.
Other companies can set up public servers which offer the same service to anyone's personal computer, again just change the target domain in the computer's config. From there it's a small step to data portability laws which say that the user must be free to move his cloud of data to another service provider at will.
You still have a problem when the network goes down, but that's it.
One day you will pay for things--any things--with your phone. It's a technical reality today, there just hasn't been that "aha" moment yet. Throw in a little infrastructure and an industry organization to coordinate standards for exchanging data and there you go.
Take your iphone to walmart, load up a cart. Go to a checkout and plug in a data cable/wave near a bluetooth scanner while running a payment app. Confirm the transaction and amount with a button on your screen. Your purchase shows up as a charge on your next "phone" bill or, after the process gets streamlined further and phone companies get in to the credit business more directly, it is charged to your bank account more directly.
Hard disk drives are banned. Where is everything going to back up too? RAM is certainly not going to cut it, especially as you run out of power.
RTFA: Flash drives, but not hard disks. Where did you think they stored the apps, in ROM? You can get several gigs this way, cheap, and cache the hell out of your data.
People who were surprised when functionality went away with 4.0 apps clearly do not remember the horror of GNOME 2.0.
GNOME 1.4 was featureful. Many say ugly, hard to fathom, riddled with UI problems and so forth... but it had a ton of stuff and lots of nice features hidden in this or that nook and cranny. When 2.0 came out I found that basic things were just gone, most apps had serious holes in them that their previous versions had had, etc.. It was a lot like KDE 4.0 but without the "wow, this is something new and interesting" feel to it. It was slower, had fewer themes, fewer features and a lot of arbitrary, bad UI convention.
If GNOME ever goes to a new, incompatible toolkit it will be KDE4 all over again but so, so much worse.
That said, it's possible that it could work like this:
- google search results effectively take care of pre-tagging images
- the sketched shape is used to match similar shapes in returned images
I still have no idea how you'd do the background thing and the results would in no way be as good as advertised.
Replace the Gecko rendering engine with the Chromium engine or the WebKit/KHTML engine and keep all the Firefox stuff on top. Correct me if I'm wrong, but Gecko doesn't implement the plugins, bookmarks, and so on -- that's Firefox doing all that userland stuff and passing anything relevant down to the Gecko engine... which it could just as easily pass down to the Chromium engine for example.
In theory one could replace gecko with e.g. webkit, but in practice one can't. Does webkit do XUL? No, so right there you see that it isn't as simple as 'porting' GNU tools to other Unix-like systems, or as simple as e.g. porting the BSD userland and replacing GNU tools on Linux. I stand by what I said: The analogy is not very good. Firefox is intrinsically tied to Gecko.
It never was relevant. Never. Only a hijacking of the name ("Linux") that we chose for ourselves.
If you never thought it was a good idea you obviously would still not think it was a good idea. Those who supported its use, such as myself, is the audience to which I was speaking. Even if GNU/Linux was once a good idea, it is no longer relevant.
It is a hierarchical key=value store with access controls.
Is it bad to have such a thing? No. But the registry is still bad.
If you wanted to create a common configuration store that worked this way you would be best advised to simply create a directory and populate it with files. This drastically reduces the chance that corruption can destroy your configuration store. It also assures that you need not create an entire suite of specialized tools just to create and alter configuration data.
Some config files are just collections of key value pairs, in which case they could be placed in to a general hierarchical configuration store. But, a lot of config files are really scripts (obvious examples:.profile,.emacsrc, but in fact most configuration can be seen as scripts) and not well suited to such a simple representation. On Windows these things are still stored outside the registry and in their own formats, so there is no escaping the need for a million files each with its own format.
One oft cited advantage to the registry is its common access API, without the need for each app to have a parser. This is an advantage to a common storage format and says nothing about the registry as such. See the Elektra project for an example of some people who have a nice way to not be the registry and still provide a common API.
The registry is bad because it's technically bad. It's just, simply, a bad idea.
A series of differently foramtted text files is not really the best way to configure a system, either, but it has certain advantages. One advantage is manipulation via common tools, not requiring a dedicated suite of tools just for modifying config data. While a myriad of different formats is a disadvantage it is also an advantage: Each program can describe it's configuration in the manner that is best-suited for that program.
This analogy doesn't work very well. You cannot have Firefox without Gecko, but you can have the GNU userland without Linux. See, for example, HURD, Debian GNU/kFreeBSD, almost any Solaris box, and Windows.
So in the case of Firefox it *is* purely unnecessary and redundant to also reference the kernel. Now, you might argue it the other way: Gecko is the real hero here and does not require Firefox, so maybe we should be saying e.g. Gecko/Seamonkey and Gecko/Firefox and Gecko/Galeon.
All that said I don't believe the GNU/Linux thing is very relevant any more. Yes, every Linux system has and relies on software from the GNU project. But, every Linux system has and relies on non-GNU non-kernel software and, importantly, the ratio of GNU to non-GNU software now favors non-GNU, so though there is a significant contribution from GNU it is no longer so overwhelming as to suggest such high billing.
Our users wanted locking, so we did it this way:
- Add a record in a lock table when a user accesses an item in edit mode.
- Always delete any previous locks a user has when a new one is added (one lock per user).
- Delete the user's lock records when the user explicitly logs out.
- A job deletes all lock records for expired sessions (every five minutes).
- Users accessing a locked record get a read only version and a notice that another user has it locked (complete with the other user's email and phone).
The stored procedure for locking a record checks that there isn't one already before adding one and does so in a transaction. We rely on the database making a decision about who gets the lock record to make sure that simultaneous access doesn't cause problems, the theory being that the DB has better code for that kind of thing anyway.
In the case where a user was editing something, timed out, got his lock deleted, another user edits it, and then the user comes back and hits submit... this doesn't have a significant chance of happening in our environment, so we didn't worry about it. Background polling from the browser is a possible but unreliable solution. You should never rely on a well behaved client when designing a web app (or any app). A suggestion I saw elsewhere in this story about using a hidden field with a checksum is a good idea which had not occurred to me. Another possible answer is to record each version separately and include the version being updated in a hidden field on the client, then check on the server that the version you're updating is the latest.
Metacity is the poster child for UI stagnation, not enhancement. Havoc decided what a good WM would do, look like and work like and then he hard coded it. This has been tweaked a little--very, very reluctantly--in the years since. There is no UI innovation in metacity, there is no innovation of any kind unless you consider keeping things exactly the same and extremely simple (to the point where it barely works at all) to be innovations. It may be good usability, which I doubt, but it certainly isn't innovative.
But taxation isn't violent or forceful. Your right to use force resist me taking your money ends where your fist encounters my face. Obviously, there is no right to property.
Property rights exist, no one is denying that, but they are not 'natural' rights; they are granted by the government.
Natural rights, for me, are the right to life, the right to liberty and things extending from that. If you have a right to be alive you have a right to food and shelter, otherwise the right is meaningless. It would be like saying you have liberty but only within this stockade. I don't see any reason why anyone fundamentally needs the right to own things. It's more like a patent, something the government grants at cost to society in hopes of motivating industriousness.
Why the hell is his modded "Troll"?
*Fixed* layout is not friendly to different clients, but precise layout is *necessary* for any non-trivial page.
You basically are saying "there is no problem, you're just doing it wrong" -- which is bullshit. Writing web sites that display smoothly across clients and devices is *fiendishly difficult* and it should not be that way. You would not get crappy web sites that look terrible on a cell phone if it weren't too hard to do it the "right way" and still make it look good on a normal screen. The cop-out answer is "make your web pages like simple printed documents on an infinitely long sheet of paper." This is the *official* answer to "CSS doesn't do what we need it to do." But, nobody ever has (or should) listen when told "Do it our way and stop complaining."
Why do you think table-based layouts have been popular for years and are still widely used? It's because CSS doesn't give us a way to do it that actually works (CSS3 notwithstanding since it's still not widely available.)
I can only assume that you, too, have never designed a web site. Don't quote me utopian, textbook answers for how to layout a site. Tell me instead why it should be so hard to tell the client how I want the page to look. There's no reason the standard *couldn't* have a simple way to specify block level alignment, it just doesn't. There's no reason you have to rely on javascript to be able to say "the right edge of the visible page," but you do.
I think the real answer is "You shouldn't have any control over how the user sees your page, not even suggestions. Use HTML to mark up what the content is and leave it at that." CSS was supposed to be for presentation, but it's clear that it was not intended to actually allow control of presentation. In a theoretical world you could get away with just saying "Don't do that," but in the real world we're going to do it because many things are more pleasant that way (and sometimes people pay for it, too.) Since it's going to happen anyway I'd like a spec that actually lets me do it without ripping all my hair out.
I'd like to see a CSS for web developers by web developers, a little like HTML5's attempt to address real problems and not simply to satisfy some theory of good markup structure. But, I am not holding my breath. Even if it were perfect and ready tomorrow I could not rely on it for at least 5 years.
I can only assume you've never written a web page.
CSS was designed by people who never wrote web pages, either. If it had been designed by a web developer there would be a notion of the viewport and a simple way to align content. Floating boxes, 50% negative margins and javascript hacks don't count.
Even if you ignore IE (I've been doing that for years) it's still incredibly complex to precisely lay things out in the browser.
Your definition of troll is specific where it should be non-specific. A troll is someone who says something for the purpose of getting a rise out of the reader, hopefully inspiring a reply, hopefully an angry reply. "3D graphics under Linux suck, this is why I use Windows" is a classic troll in any pro-Linux place (like slashdot!)
You may not have intended it as a troll and may have merely been voicing an opinion, but it certainly reads as inflammatory and certainly looks like a troll. Why didn't you say "I never could get 3D working satisfactorily on Linux, which is why I still use Windows"? This doesn't imply that Linux is deficient and Windows is superior, so it's less likely to read like trolling.
Don't fucking buy Dell. I thought everyone knew that.
In before corporate purchase. Fire the guy who OK'd it!
Thanks. Someone mod parent up?
I didn't say it would be easy, but I think it would be inevitable. You can't get such laws passed before the services exist. First you need the services and then you need some horrific company behavior and perhaps a class action lawsuit or two, then you can get the legislation. It wouldn't be possible to do it up front.
It's not especially optimistic and it's not about faith. I think Google will go for it based on their past history but I also think that if they don't people will bail out in droves and go to a competing service. At the moment there aren't really any competitors, but if Google shows how it can be done there will be.
Remember, these guys use XMPP, they have released specs for interoperation left and right. They're likely to do it again with this, sooner or later. Doing it up front is a sure way to see your product die in the alpha stage.
Well, it's logical to Google. To the rest of the world, there are still issues with having your data stored on someone else's platform. What happens if your internet connection drops? What happens if the cloud service provider folds and takes your data with it? What happens if, in a decade's time they are bought out by BigEvilCo who leverage the vendor lock-in implicit in a cloud architecture and hold a decade's worth of your data to ransom?
Step one: Make a computer that operates in the cloud. Step two: Once people are used to this begin selling the *server* or cloud side of the service.
Now Fine Corporation, Ltd. can host its company cloud computers on its company servers using the exact same platform and protocols, just change the domain in the computer's config.
Other companies can set up public servers which offer the same service to anyone's personal computer, again just change the target domain in the computer's config. From there it's a small step to data portability laws which say that the user must be free to move his cloud of data to another service provider at will.
You still have a problem when the network goes down, but that's it.
One day you will pay for things--any things--with your phone. It's a technical reality today, there just hasn't been that "aha" moment yet. Throw in a little infrastructure and an industry organization to coordinate standards for exchanging data and there you go.
Take your iphone to walmart, load up a cart. Go to a checkout and plug in a data cable/wave near a bluetooth scanner while running a payment app. Confirm the transaction and amount with a button on your screen. Your purchase shows up as a charge on your next "phone" bill or, after the process gets streamlined further and phone companies get in to the credit business more directly, it is charged to your bank account more directly.
Hard disk drives are banned. Where is everything going to back up too? RAM is certainly not going to cut it, especially as you run out of power.
RTFA: Flash drives, but not hard disks. Where did you think they stored the apps, in ROM? You can get several gigs this way, cheap, and cache the hell out of your data.
People who were surprised when functionality went away with 4.0 apps clearly do not remember the horror of GNOME 2.0.
GNOME 1.4 was featureful. Many say ugly, hard to fathom, riddled with UI problems and so forth... but it had a ton of stuff and lots of nice features hidden in this or that nook and cranny. When 2.0 came out I found that basic things were just gone, most apps had serious holes in them that their previous versions had had, etc.. It was a lot like KDE 4.0 but without the "wow, this is something new and interesting" feel to it. It was slower, had fewer themes, fewer features and a lot of arbitrary, bad UI convention.
If GNOME ever goes to a new, incompatible toolkit it will be KDE4 all over again but so, so much worse.
Turnabout is fair play.
Beck is welcome to stop inciting other people, too.
I don't buy it either.
That said, it's possible that it could work like this:
- google search results effectively take care of pre-tagging images
- the sketched shape is used to match similar shapes in returned images
I still have no idea how you'd do the background thing and the results would in no way be as good as advertised.
Replace the Gecko rendering engine with the Chromium engine or the WebKit/KHTML engine and keep all the Firefox stuff on top. Correct me if I'm wrong, but Gecko doesn't implement the plugins, bookmarks, and so on -- that's Firefox doing all that userland stuff and passing anything relevant down to the Gecko engine... which it could just as easily pass down to the Chromium engine for example.
In theory one could replace gecko with e.g. webkit, but in practice one can't. Does webkit do XUL? No, so right there you see that it isn't as simple as 'porting' GNU tools to other Unix-like systems, or as simple as e.g. porting the BSD userland and replacing GNU tools on Linux. I stand by what I said: The analogy is not very good. Firefox is intrinsically tied to Gecko.
It never was relevant. Never. Only a hijacking of the name ("Linux") that we chose for ourselves.
If you never thought it was a good idea you obviously would still not think it was a good idea. Those who supported its use, such as myself, is the audience to which I was speaking. Even if GNU/Linux was once a good idea, it is no longer relevant.
What is the registry?
It is a hierarchical key=value store with access controls.
Is it bad to have such a thing? No. But the registry is still bad.
If you wanted to create a common configuration store that worked this way you would be best advised to simply create a directory and populate it with files. This drastically reduces the chance that corruption can destroy your configuration store. It also assures that you need not create an entire suite of specialized tools just to create and alter configuration data.
Some config files are just collections of key value pairs, in which case they could be placed in to a general hierarchical configuration store. But, a lot of config files are really scripts (obvious examples: .profile, .emacsrc, but in fact most configuration can be seen as scripts) and not well suited to such a simple representation. On Windows these things are still stored outside the registry and in their own formats, so there is no escaping the need for a million files each with its own format.
One oft cited advantage to the registry is its common access API, without the need for each app to have a parser. This is an advantage to a common storage format and says nothing about the registry as such. See the Elektra project for an example of some people who have a nice way to not be the registry and still provide a common API.
The registry is bad because it's technically bad. It's just, simply, a bad idea.
A series of differently foramtted text files is not really the best way to configure a system, either, but it has certain advantages. One advantage is manipulation via common tools, not requiring a dedicated suite of tools just for modifying config data. While a myriad of different formats is a disadvantage it is also an advantage: Each program can describe it's configuration in the manner that is best-suited for that program.
Dude, that is so not funny. Don't even joke about things like that.
This analogy doesn't work very well. You cannot have Firefox without Gecko, but you can have the GNU userland without Linux. See, for example, HURD, Debian GNU/kFreeBSD, almost any Solaris box, and Windows.
So in the case of Firefox it *is* purely unnecessary and redundant to also reference the kernel. Now, you might argue it the other way: Gecko is the real hero here and does not require Firefox, so maybe we should be saying e.g. Gecko/Seamonkey and Gecko/Firefox and Gecko/Galeon.
All that said I don't believe the GNU/Linux thing is very relevant any more. Yes, every Linux system has and relies on software from the GNU project. But, every Linux system has and relies on non-GNU non-kernel software and, importantly, the ratio of GNU to non-GNU software now favors non-GNU, so though there is a significant contribution from GNU it is no longer so overwhelming as to suggest such high billing.
But even if it is struck down you will still be French.
Badum-ching! Thanks folks, hold your applause. I'll be here all week. Try the veal.
Our users wanted locking, so we did it this way:
- Add a record in a lock table when a user accesses an item in edit mode.
- Always delete any previous locks a user has when a new one is added (one lock per user).
- Delete the user's lock records when the user explicitly logs out.
- A job deletes all lock records for expired sessions (every five minutes).
- Users accessing a locked record get a read only version and a notice that another user has it locked (complete with the other user's email and phone).
The stored procedure for locking a record checks that there isn't one already before adding one and does so in a transaction. We rely on the database making a decision about who gets the lock record to make sure that simultaneous access doesn't cause problems, the theory being that the DB has better code for that kind of thing anyway.
In the case where a user was editing something, timed out, got his lock deleted, another user edits it, and then the user comes back and hits submit... this doesn't have a significant chance of happening in our environment, so we didn't worry about it. Background polling from the browser is a possible but unreliable solution. You should never rely on a well behaved client when designing a web app (or any app). A suggestion I saw elsewhere in this story about using a hidden field with a checksum is a good idea which had not occurred to me. Another possible answer is to record each version separately and include the version being updated in a hidden field on the client, then check on the server that the version you're updating is the latest.
Metacity is the poster child for UI stagnation, not enhancement. Havoc decided what a good WM would do, look like and work like and then he hard coded it. This has been tweaked a little--very, very reluctantly--in the years since. There is no UI innovation in metacity, there is no innovation of any kind unless you consider keeping things exactly the same and extremely simple (to the point where it barely works at all) to be innovations. It may be good usability, which I doubt, but it certainly isn't innovative.
Ahh, bad day to be without mod points!