I know you're joking but they actually just occasionally asked a few stupid questions like "what are the main components of the New Shiny DotNet Three Point Five Framework", "what does this PowerShell script do", etc. It's MS ITAD, you can probably get more info by googling things like "msdnaa" or "it academic day".
One of the prizes was boxed Office 2007, at least you can sell it and earn a few bucks.
I have met some interesting people there, and I was free to not attend any classes that day, so it was a nice day, all in all. And it was funny to watch that girl admitting that Windows Server is finally (albeit slowly) catching up with Unix.
They rewrote the stack for the W2K8, aka NT6.1. A nice girl was praising the new shiny Windows 2008 Server on the MS IT Academic Day at my uni last year. My friend won an USB pendrive:)
Wait, wait a moment. If the video driver crashes on Linux, the most optimistic case is restarting the X server. If Vista could actually restart the video driver and have nothing else "damaged" along the way, isn't it a lot like a microkernel or what? That is seriously something worth investigating.
Also see: "organized religion is bad" == atheist, "it seems that what you think of the world has a great impact on how it works for you" == stupid new age kid, "Linux (sucks|has certain flaws)" == windows luser | troll, "love IS an answer to SOME of our problems" == dirty hippie, and many many many many more idiotic generalizations by narrow-minded people. Yeah, I've been called like that many times, despite being neither of these.
One thing I do not yet understand is why all modern distros targeted at at least "mid-end" hardware (say, you won't probably try to run Ubuntu with less than 128MB of RAM) are compiled for >=486. As far as I recall, the original Pentium was 586 and Pentium Pro was the 686. How many of the <=586s have you seen "in the wild", running Ubuntu? Or at all, for that matter?
> I worry for you if you ever have to deal with regular real terrorism.
In my part of the world (central Europe) terrorism is as common as flying pigs (well, you can put a pig on a catapult and launch it to hell). If I were to be afraid, I'd rather be afraid of going out at evening (my sister has been robbed 30m away from our home, my neighbor has been beaten to unconsciousness, etc). But I've been living here for > 18 months and I yet have to run into any trouble. So, no, thanks, you don't have to worry.
> You do realize that there will have to be an easy and efficient GUI?
Yes, I do. I actually have more ideas on UI design than I have on this ODB. Maybe one day I'd do a few mockups, but for now a description would have to be sufficient.
Well, you open the "file" manager, it looks almost the same as it would on a normal system, except for a few minor details. You have a very clearly exposed search box at the top of the window (where an address bar would go normally), where you type search queries. For your non-technical user, it would have a "simplified" syntax: a logical OR between all space-separated strings of alphanums, exactly the way it works in Amarok. Optionally a minus or an exclamation mark for excluding the term from results. It works with Google, it works with Spotlight, why shouldn't it work in a "file" manager?
Then, the main view, is split horizontally into two areas: one for tags matching the query, and one for objects themselves. Initially, the tag view would be populated with five or ten most used tags (like Music, Video, Projects, etc), and clicking on a tag would automatically narrow the search results (it would simply add the literal value of the tag to the search query). As you add tags to the search query, the tag view would exclude tags that no object matching the query would have - so if you don't have any videos tagged "funny", and a few pics tagged funny, the "funny" tag will disappear from the tag view when you narrow your search to include only videos.
The second view would simply list the first few objects matching the query, sorted by relevance (for example, the projects you worked on recently would go first). If it turns out that the results do not include what you were looking for, you can narrow the search OR click a pretty "show more results" button at the bottom of the window until you got it.
As of editing the metadata... Hm. There's one "tag" associated with every file we have in our "classic" file systems: its name (often also describing its type, via extension). The most relevant objects (the three or five ones that "best fit" the query) would have more metadata displayed next to their icon, and editing that metadata could be as simple as clicking on the text string and changing the value (as a "classic" file manager would do with a regular file name). I was thinking of some ZUI-like (zooming user interface) approach, where more metadata is displayed when you zoom into an icon. Alternatively you may just right-click and choose "edit tags" from a nice menu and poke around with a simple tag editor that would open in a new window. Of course tags would also be sorted by relevance (if you're searching for images, it won't display the label "image" next to every image, but rather use that space to include more useful info).
For "drag and drop" kind of people, dragging an object (or a set of objects) into an icon representing a tag would tag these objects with it... I haven't yet came up with an "obvious" way of removing tags... Well, DND is certainly less intuitive in this scheme (as would be copying objects between physical devices).
These ideas need much polishing, maybe some dumb demo programs to test them out in "the real world", but I think that the GUI for my ODB would be no less usable than a classic one.
> Also remember that people hate anything different
Yes, I know:) but there are people like me and (probably) you, who would happily learn to use anything that would boost their productivity.
Also, that argument is also an argument against any innovation; I haven't used Vista myself, but I think that once you filter out all the "it's slow" and "damn UAC" comments, the biggest annoyance is that it simply is not XP.
> Of course that assumes either a hard drive so big that (.....)
Hm, no. Initially, there would be a lot of space waste and suboptimal algorithms for object allocation, that's right. But once we'd find out typical usage patterns, it would be a lot easier to im
Sorry for a late reply, I've been a little busy (:
> I don't want my family photos to appear when I look for business-related images.
'find type:image tag:"mybusinessproject" tag:!"family"', or something like that? Tags all around.
> Some kind of path component would still be around and we'd have to > use virtual directories to access path-specific files.
For small pictures or quick notes, the "main content" could as well be stored together with the metadata in the DB. For bigger stuff, the proposed object db (let's call it ODB for short) could as well use an existing implementation of a file system as a back-end. The choice of an optimal FS would be ODB's concern. Hell, it could even use a bunch of FS's, one would support files that grow and shrink in size often, another would support large files well, another one would optimize for a crapload of small files, and yet another one would support fast online defragmentation. ODB would be able to choose the right storage pool depending on the object's class (because, for example, we know that "type:logfile" would only grow in time, and probably only the latest entries are of much interest (so we can compress the older ones), and that "type:mp3file" will probably never change its audio data stream at all).
> In the end we'd end up reimplementing what we already have on top of > that object storage model just to make sense of the flood of files
Yes, that's true. However, the "other" approach (as implemented by Nepomuk), ODB over a file system, has a great flaw. The underlying files should be private to the ODB, and no other program should be able to read or modify them. The problem is clearly seen when you, for example, manually rename the file "some artist - cool song.mp3" into "Some Artist/02 Cool Song.mp3", and have to rescan the collection, or when you use regular/bin/mv to rename a file that is under a version control, etc.
Just what would happen if you'd release a library and suddenly a compiler would let user programs freely modify private fields of all the data structures? This is how I see the current approaches to FS+"object collection" tandem bikes working at the moment.
> Some kind of path component would still be around
A path is like a pointer - it is an unique identifier pointing at a resource. To the ODB, there could be no fsckin difference between/media/music/ and 0xa2cffc65f827ad09. The path would be a detail of an implementation, just like the choice of a back-end storage system.
One thing that concerned me was: how do I know on which device an object physically exists on? My idea was to use a special tag that would point to the object that represents the storage device.
> without requiring messy low-level hacks to existing software
The legacy software would run well within this scheme - just provide it with a runtime library that would implement file system API over the ODB API. Listing the contents of/bin or/usr/bin would have the same effect as running a query asking for objects of type "executable program".
At the beginning, ODB could be implemented in the user space as a library, just like FUSE is. Then, for reasons of performance, it could slowly get moved into the kernel (so that every call to the ODB won't have to go through all the layers supporting the FS).
As ultranova stated below, getting this into the Linux kernel would be next to impossible:) So that's why I've been thinking about coming up with a new system programming language (fixing the shortcomings of C along the way), that would use ODB's objects as its format for source code, and then writing an ODB-oriented operating system using that bootstrap environment. And as I have stated in my original post, writing even a simple OS in C turned out to be an overkill:)
> I don't really see file systems as we know them going away
I know that, and that's sad. Because, well, they suck, but we're kinda stuck with them at this moment.
Actually, the last one being the only effective one.
Terrorists are literally no longer terrorists if you are not afraid of them.
By that definition, US govt is more of a terrorist than an average terrorist. I'm actually more afraid of what could a government do to "try to stop the terrorists" than what terrorists themselves might do to me.
Treat every document (text file, source code, song, album, web page, picture, movie, contact, email message, etc) as an object, with associated tags: class, interfaces, metadata, etc, and store it in a database.
Locate the objects by querying the database, not by going through a hierarchical tree (eg. 'find-object type:program, name:"python" version:2.5' instead of "/usr/bin/python2.5" - yeah, more typing, but consider this: when the object is not found, the system already has ALL the info necessary to download and install it, and all of its dependencies - just catch the exception thrown when "no matches found in local storage", invoke apt-get like magic on it, retry).
Remove the distinction between "regular" memory and cache, and just make whole RAM a big cache for accessing on-disk objects. Ensure object persistence across reboots - no more shutting down, hibernation the only way. No swap file or partition needed - the whole disk is a swap area. The anonymous memory (the malloc()/new one) is no longer anonymous - it belongs to the process object. Versioning - use the free space to hold older revisions of every object (unless explicitly marked not to do so - in case of/var like stuff or highly confidential data), and rm old backups as more space is needed for "current" (or more recent) objects.
Permissions - get rid of Unix permissions or ACLs and use capabilities, eventually use different namespaces for each running process (like Plan9 does it). Get rid of all-powerful root.
Exchange of objects over the network? Serialization (for example, turn the "image" object into a regular jpg or png, store other metadata in associated xml file, and pack everything into a zip or gzipped tarball).
Legacy apps? Implement the traditional file system API in a library, some LD_PRELOAD tricks or whatever. For example every object with a "type: program" tag would be accessible from/bin/,/sbin,/usr/bin...
The only problem?
$ apt-cache search ".*"|wc -l
25221
The transition would be ***painful***.
Anyway, if I'd be doing an OS from scratch (I tried some time ago - definitely not a task for a team of one human), that's how I'd do it.
> While this might positively applicaple for e.g. victims
My life was far from painless, but I regret no single decision and want no memory to definitely fade away. I treat every unpleasant moment, every "evil" done to me as a lesson, and forgetting what I've learned would be like... devolution. It's my personal point of view, but I believe that everything that ever happened to someone, had happened for a reason.
> they can get them into games easier in an MMO than in multiple sequels.
Erm... Make one, good, flexible engine and then just add content?
Jedi Academy could have had dozens of sequels (modding it was really easy), and I know I (and many others) would play all of them. Just look at how much content was created by the community:
There still are new files on jk3.filefront.com almost every day, still after five years since the game release.
If I were LucasArts, I'd go to the community and ask them for the ideas for the engine. Then I'd take the time developing it, making it fast, flexible, extendable, stable, etc. and base a crapload of games on it. And if each of these games was as hackable as JK3...
Actually, I think that it is its job to make us __UN__happy. Don't you see how they're trying to suspend all our rights, one by one, take away all our personal freedom and privacy, keep us frightened of the "terrorists", scare us with all the crap on the news every evening?
> As I see it, the various manifestations of unhappiness: anger, worry, fear, > etc are adaptations to an uncertain environment.
As I see it, the governments and religions of the world are doing a great job of creating and maintaining an environment that is anger-, worry- and fear-"friendly".
> If you remove all the bad things that would trigger unhappiness, > then the person's unhappiness will find other things to trigger on
This is because the root cause, the "seed" of our unhappiness has been planted millennia ago, and removing it from oneself takes a great deal of strong will, self-help, and awareness. This is not a coincidence that all religions revolve around the idea of an "original sin" - although they promise to bring you "salvation", it's only you who can save yourself. By misguiding you, they make it even harder.
Formerly religions, now governments - are brainwashing us, trying their best to keep us uninformed, to control us. It's not a process that has only started yesterday... They were doing it since the day two, and they were so good at it throughout the lifetime of the mankind, that even if I tell you, here and now, that all it takes to be happy is to truly love oneself, you will most probably call bullshit on this and won't even bother thinking about it for a while.
Seriously, you're an idiot for taking part in his game. Don't you see he's having a great time trolling here? His goals are not spreading anti-"M$", "pro-OSS" BS, his goal is having fun of people like you -- people who think they will be so cool when they'll point out how stupid they think he is. You are feeding the troll. Damnit, just ignore him, it's *that* easy!
Slashdot Mirror
http://encyclopediadramatica.com/RMS
...
YOU MADE ME WASTE 4 HOURS READING THIS SHIT
I HATE YOU
it was fun
I know you're joking but they actually just occasionally asked a few stupid questions like "what are the main components of the New Shiny DotNet Three Point Five Framework", "what does this PowerShell script do", etc. It's MS ITAD, you can probably get more info by googling things like "msdnaa" or "it academic day".
One of the prizes was boxed Office 2007, at least you can sell it and earn a few bucks.
I have met some interesting people there, and I was free to not attend any classes that day, so it was a nice day, all in all. And it was funny to watch that girl admitting that Windows Server is finally (albeit slowly) catching up with Unix.
They rewrote the stack for the W2K8, aka NT6.1. A nice girl was praising the new shiny Windows 2008 Server on the MS IT Academic Day at my uni last year. My friend won an USB pendrive :)
Wait, wait a moment. If the video driver crashes on Linux, the most optimistic case is restarting the X server. If Vista could actually restart the video driver and have nothing else "damaged" along the way, isn't it a lot like a microkernel or what? That is seriously something worth investigating.
2001 called, they want their penguin racing game back.
http://en.wikipedia.org/wiki/Tux_Racer
Actually a branch of Tux Racer has been developed as non-free software.
Also see: "organized religion is bad" == atheist, "it seems that what you think of the world has a great impact on how it works for you" == stupid new age kid, "Linux (sucks|has certain flaws)" == windows luser | troll, "love IS an answer to SOME of our problems" == dirty hippie, and many many many many more idiotic generalizations by narrow-minded people. Yeah, I've been called like that many times, despite being neither of these.
Have the /users/ tag stuff, problem solved?
Man, can you share that jpg? :D
One thing I do not yet understand is why all modern distros targeted at at least "mid-end" hardware (say, you won't probably try to run Ubuntu with less than 128MB of RAM) are compiled for >=486. As far as I recall, the original Pentium was 586 and Pentium Pro was the 686. How many of the <=586s have you seen "in the wild", running Ubuntu? Or at all, for that matter?
That Ulteo Application Something smells like a custom Linux distro.
> I worry for you if you ever have to deal with regular real terrorism.
In my part of the world (central Europe) terrorism is as common as flying pigs (well, you can put a pig on a catapult and launch it to hell). If I were to be afraid, I'd rather be afraid of going out at evening (my sister has been robbed 30m away from our home, my neighbor has been beaten to unconsciousness, etc). But I've been living here for > 18 months and I yet have to run into any trouble. So, no, thanks, you don't have to worry.
> You do realize that there will have to be an easy and efficient GUI?
:) but there are people like me and (probably) you, who would happily learn to use anything that would boost their productivity.
Yes, I do. I actually have more ideas on UI design than I have on this ODB. Maybe one day I'd do a few mockups, but for now a description would have to be sufficient.
Well, you open the "file" manager, it looks almost the same as it would on a normal system, except for a few minor details. You have a very clearly exposed search box at the top of the window (where an address bar would go normally), where you type search queries. For your non-technical user, it would have a "simplified" syntax: a logical OR between all space-separated strings of alphanums, exactly the way it works in Amarok. Optionally a minus or an exclamation mark for excluding the term from results. It works with Google, it works with Spotlight, why shouldn't it work in a "file" manager?
Then, the main view, is split horizontally into two areas: one for tags matching the query, and one for objects themselves. Initially, the tag view would be populated with five or ten most used tags (like Music, Video, Projects, etc), and clicking on a tag would automatically narrow the search results (it would simply add the literal value of the tag to the search query). As you add tags to the search query, the tag view would exclude tags that no object matching the query would have - so if you don't have any videos tagged "funny", and a few pics tagged funny, the "funny" tag will disappear from the tag view when you narrow your search to include only videos.
The second view would simply list the first few objects matching the query, sorted by relevance (for example, the projects you worked on recently would go first). If it turns out that the results do not include what you were looking for, you can narrow the search OR click a pretty "show more results" button at the bottom of the window until you got it.
As of editing the metadata... Hm. There's one "tag" associated with every file we have in our "classic" file systems: its name (often also describing its type, via extension). The most relevant objects (the three or five ones that "best fit" the query) would have more metadata displayed next to their icon, and editing that metadata could be as simple as clicking on the text string and changing the value (as a "classic" file manager would do with a regular file name). I was thinking of some ZUI-like (zooming user interface) approach, where more metadata is displayed when you zoom into an icon. Alternatively you may just right-click and choose "edit tags" from a nice menu and poke around with a simple tag editor that would open in a new window. Of course tags would also be sorted by relevance (if you're searching for images, it won't display the label "image" next to every image, but rather use that space to include more useful info).
For "drag and drop" kind of people, dragging an object (or a set of objects) into an icon representing a tag would tag these objects with it... I haven't yet came up with an "obvious" way of removing tags... Well, DND is certainly less intuitive in this scheme (as would be copying objects between physical devices).
These ideas need much polishing, maybe some dumb demo programs to test them out in "the real world", but I think that the GUI for my ODB would be no less usable than a classic one.
> Also remember that people hate anything different
Yes, I know
Also, that argument is also an argument against any innovation; I haven't used Vista myself, but I think that once you filter out all the "it's slow" and "damn UAC" comments, the biggest annoyance is that it simply is not XP.
> Of course that assumes either a hard drive so big that (.....)
Hm, no. Initially, there would be a lot of space waste and suboptimal algorithms for object allocation, that's right. But once we'd find out typical usage patterns, it would be a lot easier to im
Sorry for a late reply, I've been a little busy (:
/bin/mv to rename a file that is under a version control, etc.
/media/music/ and 0xa2cffc65f827ad09. The path would be a detail of an implementation, just like the choice of a back-end storage system.
/bin or /usr/bin would have the same effect as running a query asking for objects of type "executable program".
:) So that's why I've been thinking about coming up with a new system programming language (fixing the shortcomings of C along the way), that would use ODB's objects as its format for source code, and then writing an ODB-oriented operating system using that bootstrap environment. And as I have stated in my original post, writing even a simple OS in C turned out to be an overkill :)
> I don't want my family photos to appear when I look for business-related images.
'find type:image tag:"mybusinessproject" tag:!"family"', or something like that? Tags all around.
> Some kind of path component would still be around and we'd have to
> use virtual directories to access path-specific files.
For small pictures or quick notes, the "main content" could as well be stored together with the metadata in the DB. For bigger stuff, the proposed object db (let's call it ODB for short) could as well use an existing implementation of a file system as a back-end. The choice of an optimal FS would be ODB's concern. Hell, it could even use a bunch of FS's, one would support files that grow and shrink in size often, another would support large files well, another one would optimize for a crapload of small files, and yet another one would support fast online defragmentation. ODB would be able to choose the right storage pool depending on the object's class (because, for example, we know that "type:logfile" would only grow in time, and probably only the latest entries are of much interest (so we can compress the older ones), and that "type:mp3file" will probably never change its audio data stream at all).
> In the end we'd end up reimplementing what we already have on top of
> that object storage model just to make sense of the flood of files
Yes, that's true. However, the "other" approach (as implemented by Nepomuk), ODB over a file system, has a great flaw. The underlying files should be private to the ODB, and no other program should be able to read or modify them. The problem is clearly seen when you, for example, manually rename the file "some artist - cool song.mp3" into "Some Artist/02 Cool Song.mp3", and have to rescan the collection, or when you use regular
Just what would happen if you'd release a library and suddenly a compiler would let user programs freely modify private fields of all the data structures? This is how I see the current approaches to FS+"object collection" tandem bikes working at the moment.
> Some kind of path component would still be around
A path is like a pointer - it is an unique identifier pointing at a resource. To the ODB, there could be no fsckin difference between
One thing that concerned me was: how do I know on which device an object physically exists on? My idea was to use a special tag that would point to the object that represents the storage device.
> without requiring messy low-level hacks to existing software
The legacy software would run well within this scheme - just provide it with a runtime library that would implement file system API over the ODB API. Listing the contents of
At the beginning, ODB could be implemented in the user space as a library, just like FUSE is. Then, for reasons of performance, it could slowly get moved into the kernel (so that every call to the ODB won't have to go through all the layers supporting the FS).
As ultranova stated below, getting this into the Linux kernel would be next to impossible
> I don't really see file systems as we know them going away
I know that, and that's sad. Because, well, they suck, but we're kinda stuck with them at this moment.
Actually, the last one being the only effective one.
Terrorists are literally no longer terrorists if you are not afraid of them.
By that definition, US govt is more of a terrorist than an average terrorist. I'm actually more afraid of what could a government do to "try to stop the terrorists" than what terrorists themselves might do to me.
Why not the other way around?
/var like stuff or highly confidential data), and rm old backups as more space is needed for "current" (or more recent) objects.
/bin/, /sbin, /usr/bin...
Get rid of the file system at the OS level.
Treat every document (text file, source code, song, album, web page, picture, movie, contact, email message, etc) as an object, with associated tags: class, interfaces, metadata, etc, and store it in a database.
Locate the objects by querying the database, not by going through a hierarchical tree (eg. 'find-object type:program, name:"python" version:2.5' instead of "/usr/bin/python2.5" - yeah, more typing, but consider this: when the object is not found, the system already has ALL the info necessary to download and install it, and all of its dependencies - just catch the exception thrown when "no matches found in local storage", invoke apt-get like magic on it, retry).
Remove the distinction between "regular" memory and cache, and just make whole RAM a big cache for accessing on-disk objects. Ensure object persistence across reboots - no more shutting down, hibernation the only way. No swap file or partition needed - the whole disk is a swap area. The anonymous memory (the malloc()/new one) is no longer anonymous - it belongs to the process object. Versioning - use the free space to hold older revisions of every object (unless explicitly marked not to do so - in case of
Permissions - get rid of Unix permissions or ACLs and use capabilities, eventually use different namespaces for each running process (like Plan9 does it). Get rid of all-powerful root.
Exchange of objects over the network? Serialization (for example, turn the "image" object into a regular jpg or png, store other metadata in associated xml file, and pack everything into a zip or gzipped tarball).
Legacy apps? Implement the traditional file system API in a library, some LD_PRELOAD tricks or whatever. For example every object with a "type: program" tag would be accessible from
The only problem?
$ apt-cache search ".*"|wc -l
25221
The transition would be ***painful***.
Anyway, if I'd be doing an OS from scratch (I tried some time ago - definitely not a task for a team of one human), that's how I'd do it.
I think this is how all the dupes get into the front page.
> While this might positively applicaple for e.g. victims
My life was far from painless, but I regret no single decision and want no memory to definitely fade away. I treat every unpleasant moment, every "evil" done to me as a lesson, and forgetting what I've learned would be like... devolution. It's my personal point of view, but I believe that everything that ever happened to someone, had happened for a reason.
> they can get them into games easier in an MMO than in multiple sequels.
Erm... Make one, good, flexible engine and then just add content?
Jedi Academy could have had dozens of sequels (modding it was really easy), and I know I (and many others) would play all of them. Just look at how much content was created by the community:
http://lucasfiles.com/?action=category&id=57
http://jediknight3.filefront.com/
There still are new files on jk3.filefront.com almost every day, still after five years since the game release.
If I were LucasArts, I'd go to the community and ask them for the ideas for the engine. Then I'd take the time developing it, making it fast, flexible, extendable, stable, etc. and base a crapload of games on it. And if each of these games was as hackable as JK3...
try this:
while read l; do for i in `echo $l`; do echo -ne "\\$i"; done; done > a.out
What about kernels written in type-safe languages? (Singularity, all the Java OSs)
In these systems, ALL the programs are run in one address space. Does it make the whole OS (not just the kernel) monolithic or what?...
> I think the "seed" is much, much older than that and long predates even the
:)
> existence of the human race, perhaps even the existence of mammals.
I think it predates the birth of the universe. Well, but I believe in reincarnation and that the reality happens inside one's mind
> It isn't government's job to make people happy.
Actually, I think that it is its job to make us __UN__happy. Don't you see how they're trying to suspend all our rights, one by one, take away all our personal freedom and privacy, keep us frightened of the "terrorists", scare us with all the crap on the news every evening?
http://yro.slashdot.org/comments.pl?sid=992533&cid=25337003
> As I see it, the various manifestations of unhappiness: anger, worry, fear,
> etc are adaptations to an uncertain environment.
As I see it, the governments and religions of the world are doing a great job of creating and maintaining an environment that is anger-, worry- and fear-"friendly".
> If you remove all the bad things that would trigger unhappiness,
> then the person's unhappiness will find other things to trigger on
This is because the root cause, the "seed" of our unhappiness has been planted millennia ago, and removing it from oneself takes a great deal of strong will, self-help, and awareness. This is not a coincidence that all religions revolve around the idea of an "original sin" - although they promise to bring you "salvation", it's only you who can save yourself. By misguiding you, they make it even harder.
Formerly religions, now governments - are brainwashing us, trying their best to keep us uninformed, to control us. It's not a process that has only started yesterday... They were doing it since the day two, and they were so good at it throughout the lifetime of the mankind, that even if I tell you, here and now, that all it takes to be happy is to truly love oneself, you will most probably call bullshit on this and won't even bother thinking about it for a while.
> We humans have millenia of experience in dealing with conflicts of interest.
/. reader, whose name I didn't remember: "[people] working a job they hate to earn money they don't want to buy stuff they don't need."
How great it is that we have all this invaluable experience! It surely makes humanity as a whole a better kind, and each human a better person.
Now tell me, why this shit doesn't work.
Tell me, why people are not happy.
To quote a
> But how many of them will actually make it into usable devices, if any?
They're irrelevant until they speak x86.
Seriously, you're an idiot for taking part in his game. Don't you see he's having a great time trolling here? His goals are not spreading anti-"M$", "pro-OSS" BS, his goal is having fun of people like you -- people who think they will be so cool when they'll point out how stupid they think he is. You are feeding the troll. Damnit, just ignore him, it's *that* easy!
Really, think about it.