Should it be possible to freely mix inline and block elements? In particular, place block elements inside inline elements? Basic HTML says no. CSS2 is vague, especially considering that an element's block/inline property is variable. Most browsers seem to side with HTML. But, coming from the TeX world, where \hbox and \vbox can be freely mixed to achieve any layout you like, I can see no compelling reason for prohibiting it. HTML/CSS can come across as hopelessly broken when you know that something analogous has been done for ages, and practically perfectly, elsewhere. Is the problem here with CSS, HTML, the browsers, or me?
The problem with the flat pricing mechanism is that a $9.95 flat fee would work well for big movie studios whose products are known and in demand,
Oh boy, I can't wait for the next Miramax Pictures release. Their producers are sooo hot!
but will be very bad for small film studios because many people won't pay that much for a movie that might suck "because it's not a big name movie."
Which is exactly why theatre chains only charge $5 admission for indie flicks.
No, wait, that's in Bizarro world.
Re:probably on Microsoft's list of next important
on
Apache down, IIS up
·
· Score: 1
I'd be willing to bet that Microsoft isn't solving any business problems by converting anyone to IIS.
Be careful how you phrase your bets - I'd say they are solving their own business problems.
Re:probably on Microsoft's list of next important
on
Apache down, IIS up
·
· Score: 1
It's the RAT traps that need work. Yes, you can scale up a standard mouse trap to 25cm long, crank that thing up to full power using both hands and one foot, and be careful not to whack all of your fingers off by mis-setting it, but when that thing goes off like a rifle shot in your kitchen, catching the rat full-on, right in the back of the skull, and the rat STILL DOES NOT DIE, and spends the next 30 minutes running around the kitchen, knocking over furniture, eyes bugging out, and REALLY PISSED because it can't fit down its rat hole because of the big-ass rat trap firmly clamped onto its head, that's when you know we are an inferior species and it's time to move to a new neighbourhood.
By "simple selects" I meant fast queries, not single-record queries. Whether they select multiple records or have joins or not is irrelevant, the point is that you eliminate the aspect(s) of the join that is resulting in exponential query times, and deal with that point of logic more rationally in the application layer.
Now I'm going to contradict myself, and admit that I did once write a web app that did single-record lookups only. The data structure happened to suit that approach, so I implemented it using DBM. It was scorchingly fast. So, depending on your problem, single-record queries might actually be the best choice (but in that case SQL would be the wrong choice).
What's the point of having a relational database if all you do is use it as a flat storage with all the relations done in code?
None, of course, but that's not what I was suggesting, was it? I was suggesting that when faced with queries that take minutes to resolve, you can often get orders of magnitude improvement by simplifying the query and moving some of the logic into the application.
If you prefer, you can try to get orders of magnitude improvement by reindexing or refactoring your schema, but it's really the same thing in the end (programmers hand-optimizing the problem). Unless your problem can be shoehorned into a typical SQL scenario, the advantage to tackling at the application level is that you have much more algorithmic freedom in massaging the data. More importantly, your application actually knows what the data *is* and can implement shortcuts and abstractions that are much more difficult at the DB level, where your data is just a bunch of "records" in a very inflexible format.
Simple example: say your data makes up a tree or a graph, and you need to walk the tree to determine the leaf nodes that can be reached from a particular branch. If the tree data spans different tables (say, branches, leaves, and join tables) then you can get some pretty nasty SQL queries if you try to do the work in the DB layer. Grabbing all relevant data with some simple queries, populating a tree object, and then letting the tree object tell us who our leaves are is probably going to be a lot faster, especially as the number of nodes increases.
A competent coder can always hand-optimize a problem way better than an automated optimizer. Turning on the -O switch on a compiler has only a fraction of the effect of actually understanding your algorithm and coding it properly. Understanding your data and devising your own packing format is orders of magnitude better than running it through some generic compression library. Building and tuning your own kernel based on what you know your system will be doing will give you higher performance than running an out-of-the-box system. To think that this principle magically does not apply to RBDMS is wishful thinking.
That's not to suggest you should never use left-joins or other expensive queries. Just like compiler optimizers, compression libraries, and out-of-the-box kernels, they are hugely convenient. And if the results are good enough, then why bother trying for better? If you need better, though, then you either have to do it in the application, or you have to tune or redesign the database. But tuning/redesigning the database is still hand-optimizing the problem (just in a different layer), so who really cares? You still need a competent programmer to correctly analyze the problem before you can get efficient results. Unless you're saying that you don't need to hand-optimize your problems if someone has already hand-optimized them with a well-designed, tuned, and correctly indexed DB. But that's not saying anything at all, really.
You'll find that the coders generally do multiple selects instead of a single join. They even write loops where they do two or three selects per lap in the loop where a single joined query would be enough. This isn't mysql's fault, mysql has supported joins for as long as I've used it. This is purely a case of incompetent coders.
Have you ever benchmarked multiple selects over a left join in MySQL? If you design your algorithm correctly and understand the data sets you are working with, my experience is that it's typically 10 times faster to use simple selects, and join your data in the application. "Try dumping the left join and using simple queries" is the first thing I suggest to my junior developers when they have gone and done the competent thing and ended up with a web app query that takes a full minute to return a result. Once they actually analyze the problem (instead of just trying to brute-force it with a MySQL one-liner), they usually discover there are other shortcuts and optimizations they can make, too. They may end up with 100 lines of code instead of 1 query, but they also end up with a much better application, because that 1 query was just an alias for 50,000 lines of code and a full minute of disk thrashing in MySQL.
Every household I've been to that doesn't have more than their TV's built in speakers are either very poor or don't take film watching seriously.
I'm not so poor that I couldn't afford a nice TV, and I take film watching quite seriously, but I continue to watch movies on a 13-inch TV with mono sound.
But then again, I'm part of that 0.5% of the movie-watching public who thinks the story is the most important element of a film, and from my quick scan of the features of these formats, story enhancement just isn't there yet. Oh well, perhaps next year.
White land owners have been 'the people' since before medieval times. This was not an American innovation. The American twist was that nearly any white man with some guts and a gun could become a land-owner, if he was willing to chase off the indians. This was felt to be much more egalitarian than the European model, in which all the land was already accounted for.
Unless you were an indian, of course. They had a slightly different view on freedom. Still do, for the most part.
Software as a service plainly doesn't make sense for word processing or spreadsheets.
Actually, I think it does. It's been done for over 30 years, so there's nothing new about it. It's just a minor variation on the time-sharing mainframe and remote application server model. Even in a complete GUI environment, I used to regularly run expensive commercial applications off of remote servers, and interact directly with their windows through the magic of X's network transparency. It works like a charm, it's a great way to legally use software that is too expensive to purchase, and the technology is so old it's downright boring.
Of course we had to purchase site licenses for all the relevant apps, install and serve them to our network, but changing that model to serving the apps from the software publisher straight to the internet is just a matter of scaling, and changing the billing system.
I think the only reason it doesn't seem to make sense, is that most people have never experienced true network windowing mojo, so they assume the software would have to be different in kind than it currently is, such as AJAX or something equally clunky.
I can think of another reason why it would make good sense. Modern documents are built of many elements that have different IP encumbrances - take the simple case of fonts. Good fonts cost money, and word-processor builders tend to include a limited set to keep costs down. But it sure would be nice to have access to many, many fonts (say, all of them) but only pay if you actually use them. Ditto for templates, graphics, etc.
Re:Why Then Not Now?
on
Back to the Moon
·
· Score: 3, Insightful
Why was it possible to go to the moon in '69 but not possible now even using the same old technology? Has the moon/earth/atmostphere/space changed?
A little thing called "lost technologies". It is entirely possible to forget how to do things.
A goodly portion of the knowledge encapsulated in any serious technological endeavour cannot be captured in blueprints and technical documents. It exists in the heads of the engineers, scientists, and astronauts who actually do the stuff. Going back to the original documents will give us a head start in re-learning how to do it, but not much more than that. If you don't have a teacher that actually knows how to do it, you are in the same position as someone learning how to speak Ancient Egyptian, given nothing but walls of hieroglyphics. It is possible to deduce some semblance of meaning, but it's frightfully hard to actually learn how to do it.
The primary problem is that the senior NASA engineers in 1969 are mostly dead now. They did not have any apprentices whom they could mentor in the arcane business of placing men on celestial bodies, and no young masters in that art grew up in their footsteps applying their own clever insights to refine the art further. The entire business was pretty much forgotten, and now we are back where we started, albeit with some hieroglyphics that we could spend some time trying to decode if we had to.
At Cape Canaveral, there is a complete Saturn V launcher on display at the Visitor's Centre. This is like the Great Pyramid of space missions -- a complete, working example of a device to put men on the moon. Unfortunately, they chose to lay the rocket on its side, which it was never designed to do. So structurally, the device was completely destroyed and is now useless, having even lost much of its value as an engineering archive.
So in many respects, we simply have to start over, and re-learn what we already knew.
6. Why didn't the hijackers names appear on the released passenger manifests (example)? Furthermore, why did a number of the purported hijackers did turn up alive sometime after the attacks?
7. We know that Mohammed Atta flew one of the airplanes into the WTC because we found his lightly-scorched passport lying on the streets of lower Manhattan shortly afterward. WTF?
8. Osama Bin Laden allegedly orchestrated the greatest single criminal act of terror in history against the USA, a nation that does not have a history of taking such things lightly, so why, six months later, was no-one interested in catching the guy? As early as March 2002, Bush said "I truly am not concerned about him". Is he the bogeyman or just another operator who takes orders from his handlers?
The window resize handle does the job nicely. Your problem is that you expect the "resize to fit content" button to be a maximize button instead. Expanding windows to fill all screen real estate is a legacy function from the days when people ran windowing applications on 15" and less monitors that lacked the resolution to support real graphical desktops. OS X is designed to run on 2560x1600 displays. Maximizing to fill all screen real estate would be a completely idiotic feature in such an environment, so Apple is not likely to grant your wish, and I for one am thankful. It's one of my biggest peeves about how people use Windows (hint: if you're always working in maximized windows, you're not using a windowing system!). It should be called Microsoft Screens. [/rant]
Okay, fine, you want the same story in a 12-month timeframe? My Powerbook's hard drive began a long slow failure while it was under warranty. The initial symptoms were just lots of spinning beachballs, and occasional lock-ups. I fussed with the system for a while, trying to sort out the problem, and by the time I had it pinned down to a dud HD, I was one week past the 12-month warranty period. Of course I didn't realize that until I gave up, dug out my receipts and checked the dates. ("Oh crap...")
The local Apple dealer said he couldn't honor the warranty, but told me to talk directly to Apple, since they will often make exceptions. When I called Apple, I spent all of two minutes talking to tech support, and they put me straight through to customer relations, who heard my sad story, asked me to fax them some documentation verifying my struggles with the disk, and opened up a service ticket for me so I could take it back to the dealer and have it fixed at no charge.
I agree with the original poster - it was one of the better customer service experiences of my life.
Both OSes have their strenghts and weaknesses, but out-of-the-box hardware support is definitely not Linux's strength, it is actually its main weakness.
If it's out of Dell's box, you may have a point.
But if you mean out of Microsoft's box, then you're on crack. Out-of-the-box XP simply does not work. You might have a chance if you also have all of your out-of-the-box driver CDs for all your components. But if you're in my boat, and have to install XP on mom's bare PC that she bought from who knows where, and has no clue what a driver CD is or where they might be, then you're fucked.
Unless of course you have a Knoppix CD, which will recognize almost everything, tell you what the hardware is, allow you to download the drivers and burn them to CD, just so you can get XP to realize that it has a video card and NIC. Linux's out of the box hardware support is light-years' beyond Windows.
We're relying on Media Memory to make our opinions! We should be relying on our own!
When Thoth, God of Learning and Wisdom, invented writing, he gave it
to Pharaoh, explaining the benefits that it would bring to mankind.
Writing will increase knowledge and memory, he claimed, but Pharaoh
disagreed. Writing would bring mental sloth to my people, said
Pharaoh. It will erode their memories, and replace true knowledge
with the illusion of wisdom.
The fact that the adversary, Saddam Hussein, was a murdering jackass who fancied himself another Stalin pretty much guarantees that no matter what convoluted logic the current administration used to sell the war, it'll never be considered worse than a push.
Absolutely! Any man who takes on a murdering jackass like Stalin will be vindicated by the history books! Sieg heil!
could you imagine going to a class on capitalism as a pro-capitalist when it is being taught with nothing but Marx?
Um, didn't Marx write a somewhat influential book about Capitalism? In fact, considering that he coined the word "capitalist", and practically invented the subject, I think that a course on Capitalism which didn't spend a serious amount of time on Marx would be somewhat incomplete, regardless of how you felt about the man.
But perhaps you meant a class in business, and not a class in Capitalism, in which case I'd agree with you.
PC = personal computer. All Macs ever produced have been PC's. For that matter, so were the Apple 8-bit computers.
Since you brought up 1980s terminology, you're confusing "PC" with "microcomputer". A micro is a computer that fits on your desk. PC refers to the IBM PC, and infers compatibility with that architecture.
PC is to microcomputers as Kleenex is to tissues: a brand name often misused as a generic noun. People used to keep it straight by saying "PC-compatible", but that has been contracted to just "PC" now, and the meaning has blurred correspondingly.
With Linux, OS X the worst that could happen that way is a destroyed user account.
Not true. Most *nix hacks are compound hacks involving a series of privilege escalation attacks. The root attack surface is much larger from within a user account than from out on the net, so compromising user accounts is a necessary step for many rootkits. Fortunately, since the user account is a way-station to getting more useful work done, that means user account destruction is not on the hacker's to-do list. Unfortunately, it means that unprivileged user-account compromises are very much on the hacker's to-do list.
Even it it was true that destroyed user accounts are the most you have to fear, it is small comfort when most Linux and OS X boxes are single-user machines. At best it spares you from having to reinstall the OS, but after a serious hack, you're probably wise to do that anyway.
Slashdot Mirror
Should it be possible to freely mix inline and block elements? In particular, place block elements inside inline elements? Basic HTML says no. CSS2 is vague, especially considering that an element's block/inline property is variable. Most browsers seem to side with HTML. But, coming from the TeX world, where \hbox and \vbox can be freely mixed to achieve any layout you like, I can see no compelling reason for prohibiting it. HTML/CSS can come across as hopelessly broken when you know that something analogous has been done for ages, and practically perfectly, elsewhere. Is the problem here with CSS, HTML, the browsers, or me?
Not to mention he was a much younger, and dare I say "wreckless" programmer back then.
Well Vista will ensure that he will not be wreckless for long.
The problem with the flat pricing mechanism is that a $9.95 flat fee would work well for big movie studios whose products are known and in demand,
Oh boy, I can't wait for the next Miramax Pictures release. Their producers are sooo hot!
but will be very bad for small film studios because many people won't pay that much for a movie that might suck "because it's not a big name movie."
Which is exactly why theatre chains only charge $5 admission for indie flicks.
No, wait, that's in Bizarro world.
I'd be willing to bet that Microsoft isn't solving any business problems by converting anyone to IIS.
Be careful how you phrase your bets - I'd say they are solving their own business problems.
It's the RAT traps that need work. Yes, you can scale up a standard mouse trap to 25cm long, crank that thing up to full power using both hands and one foot, and be careful not to whack all of your fingers off by mis-setting it, but when that thing goes off like a rifle shot in your kitchen, catching the rat full-on, right in the back of the skull, and the rat STILL DOES NOT DIE, and spends the next 30 minutes running around the kitchen, knocking over furniture, eyes bugging out, and REALLY PISSED because it can't fit down its rat hole because of the big-ass rat trap firmly clamped onto its head, that's when you know we are an inferior species and it's time to move to a new neighbourhood.
OT, but I had to share.
By "simple selects" I meant fast queries, not single-record queries. Whether they select multiple records or have joins or not is irrelevant, the point is that you eliminate the aspect(s) of the join that is resulting in exponential query times, and deal with that point of logic more rationally in the application layer.
Now I'm going to contradict myself, and admit that I did once write a web app that did single-record lookups only. The data structure happened to suit that approach, so I implemented it using DBM. It was scorchingly fast. So, depending on your problem, single-record queries might actually be the best choice (but in that case SQL would be the wrong choice).
What's the point of having a relational database if all you do is use it as a flat storage with all the relations done in code?
None, of course, but that's not what I was suggesting, was it? I was suggesting that when faced with queries that take minutes to resolve, you can often get orders of magnitude improvement by simplifying the query and moving some of the logic into the application.
If you prefer, you can try to get orders of magnitude improvement by reindexing or refactoring your schema, but it's really the same thing in the end (programmers hand-optimizing the problem). Unless your problem can be shoehorned into a typical SQL scenario, the advantage to tackling at the application level is that you have much more algorithmic freedom in massaging the data. More importantly, your application actually knows what the data *is* and can implement shortcuts and abstractions that are much more difficult at the DB level, where your data is just a bunch of "records" in a very inflexible format.
Simple example: say your data makes up a tree or a graph, and you need to walk the tree to determine the leaf nodes that can be reached from a particular branch. If the tree data spans different tables (say, branches, leaves, and join tables) then you can get some pretty nasty SQL queries if you try to do the work in the DB layer. Grabbing all relevant data with some simple queries, populating a tree object, and then letting the tree object tell us who our leaves are is probably going to be a lot faster, especially as the number of nodes increases.
A competent coder can always hand-optimize a problem way better than an automated optimizer. Turning on the -O switch on a compiler has only a fraction of the effect of actually understanding your algorithm and coding it properly. Understanding your data and devising your own packing format is orders of magnitude better than running it through some generic compression library. Building and tuning your own kernel based on what you know your system will be doing will give you higher performance than running an out-of-the-box system. To think that this principle magically does not apply to RBDMS is wishful thinking.
That's not to suggest you should never use left-joins or other expensive queries. Just like compiler optimizers, compression libraries, and out-of-the-box kernels, they are hugely convenient. And if the results are good enough, then why bother trying for better? If you need better, though, then you either have to do it in the application, or you have to tune or redesign the database. But tuning/redesigning the database is still hand-optimizing the problem (just in a different layer), so who really cares? You still need a competent programmer to correctly analyze the problem before you can get efficient results. Unless you're saying that you don't need to hand-optimize your problems if someone has already hand-optimized them with a well-designed, tuned, and correctly indexed DB. But that's not saying anything at all, really.
You'll find that the coders generally do multiple selects instead of a single join. They even write loops where they do two or three selects per lap in the loop where a single joined query would be enough. This isn't mysql's fault, mysql has supported joins for as long as I've used it. This is purely a case of incompetent coders.
Have you ever benchmarked multiple selects over a left join in MySQL? If you design your algorithm correctly and understand the data sets you are working with, my experience is that it's typically 10 times faster to use simple selects, and join your data in the application. "Try dumping the left join and using simple queries" is the first thing I suggest to my junior developers when they have gone and done the competent thing and ended up with a web app query that takes a full minute to return a result. Once they actually analyze the problem (instead of just trying to brute-force it with a MySQL one-liner), they usually discover there are other shortcuts and optimizations they can make, too. They may end up with 100 lines of code instead of 1 query, but they also end up with a much better application, because that 1 query was just an alias for 50,000 lines of code and a full minute of disk thrashing in MySQL.
Every household I've been to that doesn't have more than their TV's built in speakers are either very poor or don't take film watching seriously.
I'm not so poor that I couldn't afford a nice TV, and I take film watching quite seriously, but I continue to watch movies on a 13-inch TV with mono sound.
But then again, I'm part of that 0.5% of the movie-watching public who thinks the story is the most important element of a film, and from my quick scan of the features of these formats, story enhancement just isn't there yet. Oh well, perhaps next year.
Unless you were an indian, of course. They had a slightly different view on freedom. Still do, for the most part.
Software as a service plainly doesn't make sense for word processing or spreadsheets.
Actually, I think it does. It's been done for over 30 years, so there's nothing new about it. It's just a minor variation on the time-sharing mainframe and remote application server model. Even in a complete GUI environment, I used to regularly run expensive commercial applications off of remote servers, and interact directly with their windows through the magic of X's network transparency. It works like a charm, it's a great way to legally use software that is too expensive to purchase, and the technology is so old it's downright boring.
Of course we had to purchase site licenses for all the relevant apps, install and serve them to our network, but changing that model to serving the apps from the software publisher straight to the internet is just a matter of scaling, and changing the billing system.
I think the only reason it doesn't seem to make sense, is that most people have never experienced true network windowing mojo, so they assume the software would have to be different in kind than it currently is, such as AJAX or something equally clunky.
I can think of another reason why it would make good sense. Modern documents are built of many elements that have different IP encumbrances - take the simple case of fonts. Good fonts cost money, and word-processor builders tend to include a limited set to keep costs down. But it sure would be nice to have access to many, many fonts (say, all of them) but only pay if you actually use them. Ditto for templates, graphics, etc.
Why was it possible to go to the moon in '69 but not possible now even using the same old technology? Has the moon/earth/atmostphere/space changed?
A little thing called "lost technologies". It is entirely possible to forget how to do things.
A goodly portion of the knowledge encapsulated in any serious technological endeavour cannot be captured in blueprints and technical documents. It exists in the heads of the engineers, scientists, and astronauts who actually do the stuff. Going back to the original documents will give us a head start in re-learning how to do it, but not much more than that. If you don't have a teacher that actually knows how to do it, you are in the same position as someone learning how to speak Ancient Egyptian, given nothing but walls of hieroglyphics. It is possible to deduce some semblance of meaning, but it's frightfully hard to actually learn how to do it.
The primary problem is that the senior NASA engineers in 1969 are mostly dead now. They did not have any apprentices whom they could mentor in the arcane business of placing men on celestial bodies, and no young masters in that art grew up in their footsteps applying their own clever insights to refine the art further. The entire business was pretty much forgotten, and now we are back where we started, albeit with some hieroglyphics that we could spend some time trying to decode if we had to.
At Cape Canaveral, there is a complete Saturn V launcher on display at the Visitor's Centre. This is like the Great Pyramid of space missions -- a complete, working example of a device to put men on the moon. Unfortunately, they chose to lay the rocket on its side, which it was never designed to do. So structurally, the device was completely destroyed and is now useless, having even lost much of its value as an engineering archive.
So in many respects, we simply have to start over, and re-learn what we already knew.
6. Why didn't the hijackers names appear on the released passenger manifests (example)? Furthermore, why did a number of the purported hijackers did turn up alive sometime after the attacks?
7. We know that Mohammed Atta flew one of the airplanes into the WTC because we found his lightly-scorched passport lying on the streets of lower Manhattan shortly afterward. WTF?
8. Osama Bin Laden allegedly orchestrated the greatest single criminal act of terror in history against the USA, a nation that does not have a history of taking such things lightly, so why, six months later, was no-one interested in catching the guy? As early as March 2002, Bush said "I truly am not concerned about him". Is he the bogeyman or just another operator who takes orders from his handlers?
Just asking.
The window resize handle does the job nicely. Your problem is that you expect the "resize to fit content" button to be a maximize button instead. Expanding windows to fill all screen real estate is a legacy function from the days when people ran windowing applications on 15" and less monitors that lacked the resolution to support real graphical desktops. OS X is designed to run on 2560x1600 displays. Maximizing to fill all screen real estate would be a completely idiotic feature in such an environment, so Apple is not likely to grant your wish, and I for one am thankful. It's one of my biggest peeves about how people use Windows (hint: if you're always working in maximized windows, you're not using a windowing system!). It should be called Microsoft Screens. [/rant]
Under an abusive monopoly, no free market would stay that way.
Let put these statements in a jar and let them fight!
The local Apple dealer said he couldn't honor the warranty, but told me to talk directly to Apple, since they will often make exceptions. When I called Apple, I spent all of two minutes talking to tech support, and they put me straight through to customer relations, who heard my sad story, asked me to fax them some documentation verifying my struggles with the disk, and opened up a service ticket for me so I could take it back to the dealer and have it fixed at no charge.
I agree with the original poster - it was one of the better customer service experiences of my life.
The main reason why I steer clear of KDE is I'm afraid that I, too, will start talking like this.
It's pretty amazing that this whole world wide web thing got off the ground in the first place, isn't it?
If it's out of Dell's box, you may have a point.
But if you mean out of Microsoft's box, then you're on crack. Out-of-the-box XP simply does not work. You might have a chance if you also have all of your out-of-the-box driver CDs for all your components. But if you're in my boat, and have to install XP on mom's bare PC that she bought from who knows where, and has no clue what a driver CD is or where they might be, then you're fucked.
Unless of course you have a Knoppix CD, which will recognize almost everything, tell you what the hardware is, allow you to download the drivers and burn them to CD, just so you can get XP to realize that it has a video card and NIC. Linux's out of the box hardware support is light-years' beyond Windows.
We're relying on Media Memory to make our opinions! We should be relying on our own!
The fact that the adversary, Saddam Hussein, was a murdering jackass who fancied himself another Stalin pretty much guarantees that no matter what convoluted logic the current administration used to sell the war, it'll never be considered worse than a push.
Absolutely! Any man who takes on a murdering jackass like Stalin will be vindicated by the history books! Sieg heil!
could you imagine going to a class on capitalism as a pro-capitalist when it is being taught with nothing but Marx?
Um, didn't Marx write a somewhat influential book about Capitalism? In fact, considering that he coined the word "capitalist", and practically invented the subject, I think that a course on Capitalism which didn't spend a serious amount of time on Marx would be somewhat incomplete, regardless of how you felt about the man.
But perhaps you meant a class in business, and not a class in Capitalism, in which case I'd agree with you.
PC = personal computer. All Macs ever produced have been PC's. For that matter, so were the Apple 8-bit computers.
Since you brought up 1980s terminology, you're confusing "PC" with "microcomputer". A micro is a computer that fits on your desk. PC refers to the IBM PC, and infers compatibility with that architecture.PC is to microcomputers as Kleenex is to tissues: a brand name often misused as a generic noun. People used to keep it straight by saying "PC-compatible", but that has been contracted to just "PC" now, and the meaning has blurred correspondingly.
With Linux, OS X the worst that could happen that way is a destroyed user account.
Not true. Most *nix hacks are compound hacks involving a series of privilege escalation attacks. The root attack surface is much larger from within a user account than from out on the net, so compromising user accounts is a necessary step for many rootkits. Fortunately, since the user account is a way-station to getting more useful work done, that means user account destruction is not on the hacker's to-do list. Unfortunately, it means that unprivileged user-account compromises are very much on the hacker's to-do list.
Even it it was true that destroyed user accounts are the most you have to fear, it is small comfort when most Linux and OS X boxes are single-user machines. At best it spares you from having to reinstall the OS, but after a serious hack, you're probably wise to do that anyway.