By "being forced to pay for closed source development" he means "being forced to pay for closed source development with your tax money", not simply buying the software in a shop.
You're not going to get that closed software for free even if your tax money pays for it. So example situation:
Open source: $5 of your tax money goes to say, Firefox Closed source: $5 of your tax money goes to say, Matlab
The result is the same so far, except that Firefox is already available for free, so the total money spent is still $5, while you still have to buy Matlab even if your tax money contributed to it, so the total cost is $5 + $cost_of_matlab. If you don't buy it, that tax money of yours still gets spent on it.
So as I said, I don't. XP is what I want, but I refuse to get it by getting Vista first. The only option I will go with is "XP, at a normal price"
How is it illogical? It is not uncommon to find 'older' things to be more expensive than 'new' things for whatever reason. For example, original IBM Model M keyboards are quite pricey, even though they're *old*.
That one is easy, there's demand, there's little supply, and you can't make an original Model M without restarting whatever factory made them, which may have already been demolished.
Software is much different. Pressing an XP CD and pressing a Vista CD has the same cost, measured in cents. Preloading XP is unlikely to be more expensive than preloading Vista, especially since it's something that's been done for many years, and every manufacturer by now will have the process fully set up and debugged.
By all logic, XP should be cheaper.
The only reason it isn't is because Microsoft wants to sell people Vista, regardless of what they want. But that has nothing to do with the economics of CD pressing and distribution.
Manufacturers are not allowing you to do anything; they make a product and offer it for sale, and it's your choice to buy it or not. If the product does not meet your needs, expectations, or ideology, you're free to buy a different product, not buy anything at all, or go build your own.
That's how it used to work. Things aren't like this anymore.
These days, the customers aren't independent anonymous people who show up at a shop and make an independent choice about which flavor of jam to buy. These days they go on forums, communicate and organize, and when they figure out that they can pressure a manufacturer to get what they want, they go and do that, because in large enough numbers it works.
You seem to fail to realize that what you say enables this. I can say "I won't buy Vista, and won't buy XP at an extra price". For me individually this means that if MS doesn't offer the option I want, then yes, I go and use something else instead. But when it turns out that it's not just me, and there are millions of people who want the same, suddenly they become strong enough to force MS bend to their demand, because when there are that many people who want something, some of them turn out to be in control of important contracts, some willing enough to start a lawsuit, some to make their opinions widely heard, and so on. And collectively, all that, might well cost more than giving people what they want.
Manufacturers are in business to make a profit, not to respond to every whiner's whim.
Manufacturers are in the business to respond whims shared by millions of whining potential customers, because not doing that endangers their ability to make a profit.
You don't want a PC with Vista? Fine, don't buy it.
Right, so I won't
You want the PC but with XP?
Yes
Fine, buy it with Vista and install it yourself,
No, I won't pay a cent for something I don't plan to use. I very specifically don't want to reward in the slightest or appear in the usage statistics of something I don't want to touch with a 10 foot pole.
*or* pay the extra $50 or whatever and have them do it for you.
Neither. It doesn't make sense that I have to pay extra for the ability of using something older, which by all logic should be cheaper.
You were given the choice, don't bitch about it.
I wasn't given enough choice, and yes, I will bitch about it until satisfied, because that's the only way things get done these days. See the recent Facebook TOS change. Have enough people complain about it loudly enough, and things do get done.
The manufacturers aren't doing me a favour by allowing me to buy their products. I'm doing them a favour by choosing their product and paying a price, and no, I'm not going to comply with arbitrary demands and act as if their offerings were gifts from heaven.
ON DELETE CASCADE only works when you're using foreign keys as I'm sure you know. I have my doubts that facebook is using anything other than MyISAM for their databases, which of course does not support FKeys.
Fair enough about the lack of the feature in MyISAM.
My example was to show the simplicity of doing a manual delete on all tables. It was never meant to be used, so forgive the lack of caring when it comes to the validation of a variable that was likely already quite safe.
And it still misses the whole problem. Yes, performing a DELETE is trivial, in theory. It's not so necessarily trivial in practice, on a live DB with a high load and multi-gigabyte tables very possibly lacking an index on that particular column. Issuing the DELETE is easy, the problem is what to do if it takes 10 minutes to complete and makes the DB grind to a halt while it's working (and yes, that's a likely possibility on a row locking database like MyISAM)
Also a DELETE doesn't always make sense database-wise. With foreign keys, deleting the user will require finding and deleting all the entries in the log table referencing it. This is not only possibily very slow, but has strange consequences, like log entries vanishing, which would screw up reporting.
Without foreign keys, it's not much better, you'd be left with log entries pointing to user #23423 without any data describing who that user was (which quite possibly also will screw up reporting).
So yes, depending on the database, a DELETE might not be a practical option without some reorganization, or at all, and a way to mark an user as deleted instead of actually deleting the row could well be the easiest and best performing way to do it.
You sound like the kind of person that fights with programmers who don't use the do the same brace indentation as you. Get over yourself.
You sound like the kind of person who never dealt with a database of any size. While I can't claim to have worked on anything very big, I have dealt with multi-million row tables. Though this is nothing out of the ordinary in the database world, such setups already require considerable thinking about how the database is structured and accessed, because it's easy enough to create a query that takes half an hour to complete, and blocks everything else meanwhile.
Facebook is a HUGE system. Whatever issues they have to deal with are going to be a good deal more complicated than figuring out how to delete rows from tables, and if you're going to suggest their problem is so elementary, you shouldn't be surprised at getting some criticism of your "solution".
Incidentally, yes, indentation is important in large projects. It doesn't particularly matter which style is used, so long it's consistent. Having every programmer use his own way of indenting the code, naming global variables, and coding conventions is a recipe for lots of confusion, bugs, and hard to read code.
It was an example of the wrong thing though, and I thought that was worth pointing out.
The fact is, the example badly manually implements something that nearly every database, mySQL included (with ON DELETE CASCADE) supports automatically, and doesn't solve the actual problem that was being suggested ("The deletion of a user profile record would have to cascade down through every table in the database, removing every instance of that user. Who knows how long that could take.")
Of course all this is pointless speculation, but performance issues are a much more likely problem than the Facebook programmers not knowing how to delete rows from tables.
I have no idea what their environment is like, but you make a foolish assumption that $user_id hasn't already been validated and that it's actually an external variable, when realistically it would be a variable provided by the site's own authentication system since it's the user that's logged in.
Considering the code, it seems a likely possibility. However, since I can't be sure of it, I used the term "very likely", in case I happen to be guessing wrong.
I wouldn't trust some other bit of code to do the validation, in any case. Only the database itself knows how to make a string safe, which is why it's the DB what should be given that job, by using a prepared statement.
Congrats, a show of lack of understanding the problem, bad coding, and SQL injection.
1. Databases can do what you've shown automatically, with one single DELETE from one table, cascading to the rest. The problem, however, is that when you have millions of users, tables are big, and deletion can take considerable time. Perhaps one table is a multi-million row log table that is not indexed by user_id.
2. Bad coding in that you dangerously assume that user_id always refers to the same thing in every table. For user_id specifically it might, but for other names it may not be. This kind of coding will backfire badly the moment some other programmer adds an user_id column with a different purpose.
3. Very likely SQL injection due to no validation on $user_id and concatenation of a SQL query. My $user_id happens to be "0 OR 1=1", say bye to your database.
I'm not hostile to versioning. I like versioning. I used CVS, SVN, SVK, and Git.
My fundamental claim is not that there's anything wrong with versioning. It's that if you present your target user as a complete moron who is incapable of understanding the concepts of a file, and the need to save, that you can't really claim to solve this particular user's problem by introducing a much more complex versioning mechanism.
Just for a start, you somehow removed the concept of a file but added concepts of versions, tags and maybe even branches, and replaced the need to save with the need to create checkpoints.
Now if you throw out the "idiot user" idea and just say that it'd be nice if the OS allowed you to efficiently make snapshots in say, ZFS style, then that's a perfectly fine and useful thing, but nowhere near the aim of being more user friendly than the current way of saving documents.
The grandparent said "CS is not limited by technical limits, only your imagination". I'm saying that no, no amount of imagination removes fundamental limits, like limits to computation and storage, and no amount of "splitting into manageable chunks" makes an O(n!) problem with a large enough n tractable.
That this particlar problem can be solved with an approximation is beside the point. I used it because the difficulty of brute forcing the solution should be very easy to understand without any specialized knowledge.
I will repeat for the 5th or 6th time what this discussion started about:
[...] the concept of a file is horrible from a user perspective. Files are added as a concept because it is a hack and makes it easier for the programmer. A user in fact does not want to have say, "oh I have to save this?""
Now please think how would you explain your system of undo checkpoints, marked checkpoints, and draft checkpoints to the above implied target user, who finds files unintuitive and the need to save confusing.
Simple OO orientated access to a bit of everything, that's the true benefit of Phantom. You are still missing the points completely, or maybe you are just trolling? The increased intuitiviness is mostly on the development arena how i see Phantom, it will translate to some portions of the GUI definitely, and allow many neat things done which were harder on traditional OS.
As a programmer, this tells me absolutely nothing. Concrete code examples, and pointers to documentation, please.
You are arguing a technical solution is bad on the basis of the irrelevant GUI. How hard it is to see that method of how things are done and accessed beneath the curtain has no correlation on the final GUI necessarily?
We're talking here about something that necessarily must result in the user getting a different sort of behavior. If the only difference is for the programmer, and the user doesn't see any improvements, then there's no point for the user to adopt a new OS.
As for your O(n!) algo inefficiency: You take the algo, splice it on nice swallowable chunks, and all of sudden you have a nice small problem set algo;)/me works on huge datasets daily
Well, take the travelling salesman problem. You have a table of just 100 cities with their locations on the map. The problem is calculating the shortest (no approximations allowed) route for visiting all of them. Please tell me how you're going to split that into nice swallowable chunks (hint: 100! is a rather large number). Also, how much more hardware will you need if you add an extra city and want to get it done in the same amount of time?
You're really discussing three separate things here: (1) autosave, (2) keeping all the old versions around forever by default, and (3) eliminating the ability to give someone else a file without also giving them access to all the old versions. You can have 1 without 2 and 3 (commonly implemented in word processors), or 1 and 2 without 3 (as in VMS).
That is something different from what's been suggested here.
The suggestion is not saving every 5 minutes, or even automatically creating backups, but that really no save operation is required because things get saved the moment you change them, to the point that even sudden loss of power doesn't result in a loss of data. In this case, yes, you need a permanent undo because there's nothing getting asked when you close the word processor, as all the changes have been written already, and the whole concept of unsaved changes has been eliminated.
Why not just add a library that can be used with the dynamic programs that allows them to do this easily while still retaining the ability to do things the old fashioned way?
You're probably not a programmer? Saving files can get pretty complex, and is specific to the task.
Continous saving is really quite trivial to hack into a program. For instance on Linux, fork, save to temp file, replace original when done. But that's not even 10% of the task, because now that you made saving work differently the interface will need changes to support this new way of working properly. And a library can't do that automatically.
You are still missing the point, there can be a working copy (you could say this is persistant as long as user wants) and the archival copy, nothing stops implementing that feature.
There can be many things, but most of them conflict with the aim of increasing intuitiveness.
I don't disagree with that things like versioning are a good thing. My claim is that versioning adds more complications than the lack of need for explicit save removes, making it a bad tradeoff when targeting clueless users. Experts are a completely different matter.
CS is not limited by technical limits, only your imagination (and time)
Yes it is. No amount of imagination is going to make your hard disk larger, or make O(n!) algorithms efficient.
The method Phantom works does not prevent at all basic functionality such as that, infact, if wanted to all user interface and usability features can be 100% exactly the same.
If it's going to be 100% the same, there's no reason for the user to bother with it
The true benefit of Phantom's OO approach is development is far easier, and faster. Everything is reusable, recyclable, and simple objects (for the most part).
No clue what you mean here. You could be as well referring to Visual Basic, or Perl, both of which seem to fit what you said.
I want to be able to manipulate & transport objects as such, not as files.
How are you going to deal with compatibility issues in this case? What happens when the internal data structures change, new fields are added or removed?
The way I see it, for any amount of complexity you'll have to come up with an on-disk format that's nothing like the in-memory one, and then a couple lines to open/write/close files pale in comparison to the amount of work needed to do that.
Admittedly it could be hard for the average user, and it will remember the almost all of the complete historical state of the document
Stop right there. This is an admission that this theoretical user who is so confused by the need to save isn't going to do well at all dealing with revisions.
If you're talking about a specialized package designed for people who do things like editing newspaper articles or documentation and want to have all changes precisely tracked, then sure, it might be a fine idea. But this puts it completely outside of the scope of making something intuitive for a non-technical user.
Think outside the box for a moment. Nothing you brought up could not be fixed with a simple mechanism. You could still hit "save as" when you wanted a snapshot of a document but the point is that the document will persist even though you lost power in the middle of typing it.
But make sure to do that right before touching anything!
Because since saving is automatic, you can only make a backup before you start touching things. Once you start editing, it's too late.
And here's where things start getting into a bizarre territory.
The rationale for this whole idea is that poor dumb users find the concept of having to save so awfully unintuitive. But in that case, how well do you think they're going to deal with concepts of "undo levels" and "versions"? How will they know what to set the undo level to?
And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.
No one said we couldn't provide the user 'Save As' functionality or 'Save' functionality.
Oh, you can "Save as", ok. But you need to do so before any important change, and do so consistently, because the moment you start editing, your on-disk document changes!
Furthermore, it would be utterly stupid to have your current under work object be the same as the stored object... How immensively stupid it would be to spread across images with ALL of their edit history?
It's what every single office user does? Very very few users will even think about making backups. The vast majority isn't aware of that a document can be in more than one format.
Edit history is something we don't need persistence in,
Then how are you going to deal with accidental changes? If saving is automatic then obviously there's no confirmation when you close the program, and changes persist even if power goes out. There has to be a way to undo a change after the file is reopened then.
Have you read About Face from Alan Cooper? He explains in that the concept of a file is horrible from a user perspective. Files are added as a concept because it is a hack and makes it easier for the programmer. A user in fact does not want to have say, "oh I have to save this?"
Heard of this idea, and disagree completely with it.
Continous autosave isn't a technically difficult problem. It could be implemented quite easily. But it would take one minor inconvenience, and replace it with several more difficult ones.
Ok, so you don't have to save anymore. Great. But now you have to deal with that you went to make tea, and your document now has your cat walking on the keyboard saved in it. You can't simply choose not to save, you have to figure out how many changes to undo to get the document to its pre-cat state. How many times do you have to press the undo button?
Same goes for extensive modificatons. Maybe you decided to drastically reformat the document, but then decide the idea doesn't look good after all. You can't choose not to save, you've either got to undo 50 times, or have created a copy before starting making the changes.
Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.
It also removes safety: I spend much time telling people that they can't easily break anything. With this system they can. Somebody who accidentally selects and overwrites the whole document will find out that even pulling the plug won't bring the document back. Now there's one excellent way of making a newbie really freak out. What if you intentionally or by accident write something insulting in the document? How do you make the program remove the record of it?
Here's another one: Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?
Resuming: You remove one small thing, the need to explicitly save, and add the requirement of eternal undo (potential issues with embedded images here), requirement for the user to understand the undo system, requirement to design it in such a way that hours of work can be undone without getting RSI, add potential problems with disclosure of things that the user doesn't want to disclose, make it harder to do large experimental changes, and remove a way for an user to completely revert a change.
IMO this is too much of a mess for so little benefit.
Sure, but then it's nearly equivalent to Win2K for the sort of usage I'm interested in.
Maybe I'm getting old, but I've stopped feeling excited about things like wobbling windows and translucency, and "features" like the search dog just drive me bonkers. These days what I want is an OS that gets the hell out of my way as soon as it boots. I want to run my applications and deal with as few interruptions as possible.
Win2K used to provide that for the most part, but no current MS OS seems to fit those requirements anymore.
These days it's Linux what provides it. Applications don't inconsiderately interrupt demanding to be registered or updated, the update system doesn't steal focus or try to reboot my computer on its own (what the HELL is up with that?), I can open a PDF without having to wait until it loads 50 pointless plugins and then asks if I'd like to update, applications don't mess with other applications' settings, the antivirus doesn't complain about being out of date (because there isn't one), and drivers don't shove crappy monitoring/settings apps into the systray, my CPU time isn't spent enforcing DRM, and I don't have to waste my time waiting until a 100MB driver package for a device with a 50K Linux module gets downloaded.
An OS which runs fast, doesn't require an unreasonable amount of resources, and doesn't get in your way is good. An OS which is slow, requires new expensive hardware, and constantly annoys you is bad.
Back when XP came out, the benefit over Win2K was negligible. And still is really.
So why is now XP getting declared as good when before it was bloated? Several reasons:
1. You can't buy Win2K anymore. It doesn't matter if it's the best thing since sliced bread when you can't get it. 2. Hardware advanced to the point that the extra resource usage over Win2K isn't really noticeable anymore. 3. Win2K installations have largely disappeared, so it's hard to make a comparison with it anymore.
As far as I'm concerned, Win2K does precisely what I want it to do: it provides a base system to install stuff on. It doesn't do anything terribly fancy, but I don't want it to. It also doesn't have activation. But it's not a realistic option anymore with everybody dropping support for it.
So when a normal user asks me which Windows version to go to, I will tell them to go with XP, which is light and fast and more compatible than Vista. The average person isn't interested in hearing me rant about how I despise the Fisher Price interface and how Win2K was so much better, because they can't get it anyway, and if they did they could run into a compatibility problem sooner or later.
They're asking about what should they get *now*, out of what is currently on the market, not what would I consider the ideal option if I could chain the MS programmers to their desks and force them to maintain Win2K for eternity. So that's the question I answer. When having a choice between XP and Vista, which is the light one? XP.
I bet that in 2015 I'll be talking about Win7 was nice and small, and didn't need those insane requirements of 50GB disk space and 16GB RAM.
Err Umm... I was responding post that we should charge the OS Company for any security holes. At this point the argument is pointing out a problem with the proposed suggestion from an IT manager point of view. Please try to keep current, and realize proposed ideas are not ideas that are currently in place.
Ok, fair enough. My mistake.
No but they have security in different places. I have seen Unix and Linux systems broken into far more then Windows Systems, in the corporate environment.
This is anectodal evidence, I could easily provide the contrary. Did you know that there are STILL companies that run whole network of Pentium 1 boxes running Win98?
I don't think this question is as easy to decide as saying that it depends on the admin. Both sides have significant periperhal issues that change the balance. For instance, Windows costs money. Linux can be had for free. Upgrading to a newer Windows version isn't only a question of retraining, but also of the money it costs to upgrade. At some companies this results in using ridiculously old software, because really, some things run perfectly fine on a Pentium 1 with 64MB RAM, and the case for upgrading to Vista is very weak.
Sometimes the company requires using some ancient device that only has drivers for Win2K which for some reason won't work on XP.
My point here is, the resulting overall security depends on many factors, some of which are OS related, and some of which aren't. Canonical example of this is for instance that there are more installs of Apache than of IIS, yet IIS gets broken into more often.
As for you last bit about the difference in security style. I was stating a Linux admin tends to be more of a Pro then an ad hoc Windows Admin. The Ad Hoc Windows Admin will not even have the theory to back things up. While the Linux admin does. I am not saying a Linux admin is better then a Windows Admin Pro. But a Linux admin is normally a bit more of a pro then a Windows Admin in terms of probability.
Well. I'm not that sure of that. Sure, if I had to secure a Windows box, and IF I was given enough time and resources, I could probably do it better than the kind of admin you speak of. The second "if" is important though. If you need to secure an Exchange server I wouldn't have a clue how. I could figure it out, given enough time, but chances are I'm not going to get it, so you'd have been better off with a proper Windows admin.
Slashdot Mirror
By "being forced to pay for closed source development" he means "being forced to pay for closed source development with your tax money", not simply buying the software in a shop.
You're not going to get that closed software for free even if your tax money pays for it. So example situation:
Open source: $5 of your tax money goes to say, Firefox
Closed source: $5 of your tax money goes to say, Matlab
The result is the same so far, except that Firefox is already available for free, so the total money spent is still $5, while you still have to buy Matlab even if your tax money contributed to it, so the total cost is $5 + $cost_of_matlab. If you don't buy it, that tax money of yours still gets spent on it.
So as I said, I don't. XP is what I want, but I refuse to get it by getting Vista first. The only option I will go with is "XP, at a normal price"
That one is easy, there's demand, there's little supply, and you can't make an original Model M without restarting whatever factory made them, which may have already been demolished.
Software is much different. Pressing an XP CD and pressing a Vista CD has the same cost, measured in cents. Preloading XP is unlikely to be more expensive than preloading Vista, especially since it's something that's been done for many years, and every manufacturer by now will have the process fully set up and debugged.
By all logic, XP should be cheaper.
The only reason it isn't is because Microsoft wants to sell people Vista, regardless of what they want. But that has nothing to do with the economics of CD pressing and distribution.
That's how it used to work. Things aren't like this anymore.
These days, the customers aren't independent anonymous people who show up at a shop and make an independent choice about which flavor of jam to buy. These days they go on forums, communicate and organize, and when they figure out that they can pressure a manufacturer to get what they want, they go and do that, because in large enough numbers it works.
You seem to fail to realize that what you say enables this. I can say "I won't buy Vista, and won't buy XP at an extra price". For me individually this means that if MS doesn't offer the option I want, then yes, I go and use something else instead. But when it turns out that it's not just me, and there are millions of people who want the same, suddenly they become strong enough to force MS bend to their demand, because when there are that many people who want something, some of them turn out to be in control of important contracts, some willing enough to start a lawsuit, some to make their opinions widely heard, and so on. And collectively, all that, might well cost more than giving people what they want.
Manufacturers are in the business to respond whims shared by millions of whining potential customers, because not doing that endangers their ability to make a profit.
Right, so I won't
Yes
No, I won't pay a cent for something I don't plan to use. I very specifically don't want to reward in the slightest or appear in the usage statistics of something I don't want to touch with a 10 foot pole.
Neither. It doesn't make sense that I have to pay extra for the ability of using something older, which by all logic should be cheaper.
I wasn't given enough choice, and yes, I will bitch about it until satisfied, because that's the only way things get done these days. See the recent Facebook TOS change. Have enough people complain about it loudly enough, and things do get done.
The manufacturers aren't doing me a favour by allowing me to buy their products. I'm doing them a favour by choosing their product and paying a price, and no, I'm not going to comply with arbitrary demands and act as if their offerings were gifts from heaven.
Fair enough about the lack of the feature in MyISAM.
And it still misses the whole problem. Yes, performing a DELETE is trivial, in theory. It's not so necessarily trivial in practice, on a live DB with a high load and multi-gigabyte tables very possibly lacking an index on that particular column. Issuing the DELETE is easy, the problem is what to do if it takes 10 minutes to complete and makes the DB grind to a halt while it's working (and yes, that's a likely possibility on a row locking database like MyISAM)
Also a DELETE doesn't always make sense database-wise. With foreign keys, deleting the user will require finding and deleting all the entries in the log table referencing it. This is not only possibily very slow, but has strange consequences, like log entries vanishing, which would screw up reporting.
Without foreign keys, it's not much better, you'd be left with log entries pointing to user #23423 without any data describing who that user was (which quite possibly also will screw up reporting).
So yes, depending on the database, a DELETE might not be a practical option without some reorganization, or at all, and a way to mark an user as deleted instead of actually deleting the row could well be the easiest and best performing way to do it.
You sound like the kind of person who never dealt with a database of any size. While I can't claim to have worked on anything very big, I have dealt with multi-million row tables. Though this is nothing out of the ordinary in the database world, such setups already require considerable thinking about how the database is structured and accessed, because it's easy enough to create a query that takes half an hour to complete, and blocks everything else meanwhile.
Facebook is a HUGE system. Whatever issues they have to deal with are going to be a good deal more complicated than figuring out how to delete rows from tables, and if you're going to suggest their problem is so elementary, you shouldn't be surprised at getting some criticism of your "solution".
Incidentally, yes, indentation is important in large projects. It doesn't particularly matter which style is used, so long it's consistent. Having every programmer use his own way of indenting the code, naming global variables, and coding conventions is a recipe for lots of confusion, bugs, and hard to read code.
That particular wording would affect many other things though, like allowing the creation of weapons and explosives.
If I have several tons of fertilizer and fuel in my posession, this kind of wording would make it legal to combine them without limit.
It was an example of the wrong thing though, and I thought that was worth pointing out.
The fact is, the example badly manually implements something that nearly every database, mySQL included (with ON DELETE CASCADE) supports automatically, and doesn't solve the actual problem that was being suggested ("The deletion of a user profile record would have to cascade down through every table in the database, removing every instance of that user. Who knows how long that could take.")
Of course all this is pointless speculation, but performance issues are a much more likely problem than the Facebook programmers not knowing how to delete rows from tables.
How'd you guess?
Considering the code, it seems a likely possibility. However, since I can't be sure of it, I used the term "very likely", in case I happen to be guessing wrong.
I wouldn't trust some other bit of code to do the validation, in any case. Only the database itself knows how to make a string safe, which is why it's the DB what should be given that job, by using a prepared statement.
Congrats, a show of lack of understanding the problem, bad coding, and SQL injection.
1. Databases can do what you've shown automatically, with one single DELETE from one table, cascading to the rest. The problem, however, is that when you have millions of users, tables are big, and deletion can take considerable time. Perhaps one table is a multi-million row log table that is not indexed by user_id.
2. Bad coding in that you dangerously assume that user_id always refers to the same thing in every table. For user_id specifically it might, but for other names it may not be. This kind of coding will backfire badly the moment some other programmer adds an user_id column with a different purpose.
3. Very likely SQL injection due to no validation on $user_id and concatenation of a SQL query. My $user_id happens to be "0 OR 1=1", say bye to your database.
I'm not hostile to versioning. I like versioning. I used CVS, SVN, SVK, and Git.
My fundamental claim is not that there's anything wrong with versioning. It's that if you present your target user as a complete moron who is incapable of understanding the concepts of a file, and the need to save, that you can't really claim to solve this particular user's problem by introducing a much more complex versioning mechanism.
Just for a start, you somehow removed the concept of a file but added concepts of versions, tags and maybe even branches, and replaced the need to save with the need to create checkpoints.
Now if you throw out the "idiot user" idea and just say that it'd be nice if the OS allowed you to efficiently make snapshots in say, ZFS style, then that's a perfectly fine and useful thing, but nowhere near the aim of being more user friendly than the current way of saving documents.
You miss the point though.
The grandparent said "CS is not limited by technical limits, only your imagination". I'm saying that no, no amount of imagination removes fundamental limits, like limits to computation and storage, and no amount of "splitting into manageable chunks" makes an O(n!) problem with a large enough n tractable.
That this particlar problem can be solved with an approximation is beside the point. I used it because the difficulty of brute forcing the solution should be very easy to understand without any specialized knowledge.
I will repeat for the 5th or 6th time what this discussion started about:
Now please think how would you explain your system of undo checkpoints, marked checkpoints, and draft checkpoints to the above implied target user, who finds files unintuitive and the need to save confusing.
As a programmer, this tells me absolutely nothing. Concrete code examples, and pointers to documentation, please.
We're talking here about something that necessarily must result in the user getting a different sort of behavior. If the only difference is for the programmer, and the user doesn't see any improvements, then there's no point for the user to adopt a new OS.
Well, take the travelling salesman problem. You have a table of just 100 cities with their locations on the map. The problem is calculating the shortest (no approximations allowed) route for visiting all of them. Please tell me how you're going to split that into nice swallowable chunks (hint: 100! is a rather large number). Also, how much more hardware will you need if you add an extra city and want to get it done in the same amount of time?
That is something different from what's been suggested here.
The suggestion is not saving every 5 minutes, or even automatically creating backups, but that really no save operation is required because things get saved the moment you change them, to the point that even sudden loss of power doesn't result in a loss of data. In this case, yes, you need a permanent undo because there's nothing getting asked when you close the word processor, as all the changes have been written already, and the whole concept of unsaved changes has been eliminated.
You're probably not a programmer? Saving files can get pretty complex, and is specific to the task.
Continous saving is really quite trivial to hack into a program. For instance on Linux, fork, save to temp file, replace original when done. But that's not even 10% of the task, because now that you made saving work differently the interface will need changes to support this new way of working properly. And a library can't do that automatically.
There can be many things, but most of them conflict with the aim of increasing intuitiveness.
I don't disagree with that things like versioning are a good thing. My claim is that versioning adds more complications than the lack of need for explicit save removes, making it a bad tradeoff when targeting clueless users. Experts are a completely different matter.
Yes it is. No amount of imagination is going to make your hard disk larger, or make O(n!) algorithms efficient.
If it's going to be 100% the same, there's no reason for the user to bother with it
No clue what you mean here. You could be as well referring to Visual Basic, or Perl, both of which seem to fit what you said.
How are you going to deal with compatibility issues in this case? What happens when the internal data structures change, new fields are added or removed?
The way I see it, for any amount of complexity you'll have to come up with an on-disk format that's nothing like the in-memory one, and then a couple lines to open/write/close files pale in comparison to the amount of work needed to do that.
Stop right there. This is an admission that this theoretical user who is so confused by the need to save isn't going to do well at all dealing with revisions.
If you're talking about a specialized package designed for people who do things like editing newspaper articles or documentation and want to have all changes precisely tracked, then sure, it might be a fine idea. But this puts it completely outside of the scope of making something intuitive for a non-technical user.
But make sure to do that right before touching anything!
Because since saving is automatic, you can only make a backup before you start touching things. Once you start editing, it's too late.
And here's where things start getting into a bizarre territory.
The rationale for this whole idea is that poor dumb users find the concept of having to save so awfully unintuitive. But in that case, how well do you think they're going to deal with concepts of "undo levels" and "versions"? How will they know what to set the undo level to?
And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.
Oh, you can "Save as", ok. But you need to do so before any important change, and do so consistently, because the moment you start editing, your on-disk document changes!
It's what every single office user does? Very very few users will even think about making backups. The vast majority isn't aware of that a document can be in more than one format.
Then how are you going to deal with accidental changes? If saving is automatic then obviously there's no confirmation when you close the program, and changes persist even if power goes out. There has to be a way to undo a change after the file is reopened then.
Heard of this idea, and disagree completely with it.
Continous autosave isn't a technically difficult problem. It could be implemented quite easily. But it would take one minor inconvenience, and replace it with several more difficult ones.
Ok, so you don't have to save anymore. Great. But now you have to deal with that you went to make tea, and your document now has your cat walking on the keyboard saved in it. You can't simply choose not to save, you have to figure out how many changes to undo to get the document to its pre-cat state. How many times do you have to press the undo button?
Same goes for extensive modificatons. Maybe you decided to drastically reformat the document, but then decide the idea doesn't look good after all. You can't choose not to save, you've either got to undo 50 times, or have created a copy before starting making the changes.
Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.
It also removes safety: I spend much time telling people that they can't easily break anything. With this system they can. Somebody who accidentally selects and overwrites the whole document will find out that even pulling the plug won't bring the document back. Now there's one excellent way of making a newbie really freak out. What if you intentionally or by accident write something insulting in the document? How do you make the program remove the record of it?
Here's another one: Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?
Resuming: You remove one small thing, the need to explicitly save, and add the requirement of eternal undo (potential issues with embedded images here), requirement for the user to understand the undo system, requirement to design it in such a way that hours of work can be undone without getting RSI, add potential problems with disclosure of things that the user doesn't want to disclose, make it harder to do large experimental changes, and remove a way for an user to completely revert a change.
IMO this is too much of a mess for so little benefit.
Looks like it
No, it bloody isn't. That's the sort of thing malware does. My computer is mine and things on it get installed and updated only under my consent.
It's the principle of the thing. This action alone ensured nothing else of Google's will get on my computer.
Sure, but then it's nearly equivalent to Win2K for the sort of usage I'm interested in.
Maybe I'm getting old, but I've stopped feeling excited about things like wobbling windows and translucency, and "features" like the search dog just drive me bonkers. These days what I want is an OS that gets the hell out of my way as soon as it boots. I want to run my applications and deal with as few interruptions as possible.
Win2K used to provide that for the most part, but no current MS OS seems to fit those requirements anymore.
These days it's Linux what provides it. Applications don't inconsiderately interrupt demanding to be registered or updated, the update system doesn't steal focus or try to reboot my computer on its own (what the HELL is up with that?), I can open a PDF without having to wait until it loads 50 pointless plugins and then asks if I'd like to update, applications don't mess with other applications' settings, the antivirus doesn't complain about being out of date (because there isn't one), and drivers don't shove crappy monitoring/settings apps into the systray, my CPU time isn't spent enforcing DRM, and I don't have to waste my time waiting until a 100MB driver package for a device with a 50K Linux module gets downloaded.
It's very simple when you think of it.
An OS which runs fast, doesn't require an unreasonable amount of resources, and doesn't get in your way is good.
An OS which is slow, requires new expensive hardware, and constantly annoys you is bad.
Back when XP came out, the benefit over Win2K was negligible. And still is really.
So why is now XP getting declared as good when before it was bloated? Several reasons:
1. You can't buy Win2K anymore. It doesn't matter if it's the best thing since sliced bread when you can't get it.
2. Hardware advanced to the point that the extra resource usage over Win2K isn't really noticeable anymore.
3. Win2K installations have largely disappeared, so it's hard to make a comparison with it anymore.
As far as I'm concerned, Win2K does precisely what I want it to do: it provides a base system to install stuff on. It doesn't do anything terribly fancy, but I don't want it to. It also doesn't have activation. But it's not a realistic option anymore with everybody dropping support for it.
So when a normal user asks me which Windows version to go to, I will tell them to go with XP, which is light and fast and more compatible than Vista. The average person isn't interested in hearing me rant about how I despise the Fisher Price interface and how Win2K was so much better, because they can't get it anyway, and if they did they could run into a compatibility problem sooner or later.
They're asking about what should they get *now*, out of what is currently on the market, not what would I consider the ideal option if I could chain the MS programmers to their desks and force them to maintain Win2K for eternity. So that's the question I answer. When having a choice between XP and Vista, which is the light one? XP.
I bet that in 2015 I'll be talking about Win7 was nice and small, and didn't need those insane requirements of 50GB disk space and 16GB RAM.
Ok, fair enough. My mistake.
This is anectodal evidence, I could easily provide the contrary. Did you know that there are STILL companies that run whole network of Pentium 1 boxes running Win98?
I don't think this question is as easy to decide as saying that it depends on the admin. Both sides have significant periperhal issues that change the balance. For instance, Windows costs money. Linux can be had for free. Upgrading to a newer Windows version isn't only a question of retraining, but also of the money it costs to upgrade. At some companies this results in using ridiculously old software, because really, some things run perfectly fine on a Pentium 1 with 64MB RAM, and the case for upgrading to Vista is very weak.
Sometimes the company requires using some ancient device that only has drivers for Win2K which for some reason won't work on XP.
My point here is, the resulting overall security depends on many factors, some of which are OS related, and some of which aren't. Canonical example of this is for instance that there are more installs of Apache than of IIS, yet IIS gets broken into more often.
Well. I'm not that sure of that. Sure, if I had to secure a Windows box, and IF I was given enough time and resources, I could probably do it better than the kind of admin you speak of. The second "if" is important though. If you need to secure an Exchange server I wouldn't have a clue how. I could figure it out, given enough time, but chances are I'm not going to get it, so you'd have been better off with a proper Windows admin.