It'll take forever at first, but yes. Modern backup solutions would tend to be smarter still -- triggering automatically and silently in the background, sending deltas as soon as anything changes -- though presumably you could restrict how much bandwidth and what hours it would operate.
If you use the standalone computer for anything but storing the key,
Same problem occurs if I write doodles on the paper -- though I fail to see how that reduces the security, only the reliability.
or fail to physically secure the standalone computer from access
Granted, it's easier to secure a piece of paper. But the same problem applies.
More importantly, a closer analog to the paper is a USB thumb drive, which will fit just as neatly in a safety deposit box, or in your pocket, or (apparently) in your digestive system. It has flaws, but these would seem to be the exact same flaws the paper does -- for example, any machine on which I decrypt the data is necessarily a machine which will hold that key in RAM at some point, which means it's a point of failure.
The most paranoid solution I know of in that vein, which I used for awhile, is to boot off a thumb drive (which has the stored keys) and use full-disk encryption on the hard drive. I'd be pwned if and only if someone implements a BIOS-level or hardware-level exploit, and somehow does it without me noticing -- I kept a pretty close eye on that machine, physically. (Tempest would probably work, but you're not going to be left alone with it for long enough to do anything -- best case, you steal it, but then you don't have the USB key in my pocket.)
I stopped doing that when the USB key died, suddenly and completely, leaving me no way of accessing my data -- and my new laptop has an SSD, which is actually fast enough that crypto speed might be a limiting factor, whereas it definitely won't be on a 5400 RPM drive with any sort of modern CPU.
will likely be more likely to be practically usable to access data a longer time into the future.
Possible. We know a lot more about how paper degrades than we do about how data degrades (yet).
Though in this case, a key factor is making sure the paper has the key in a human-readable form as well as a machine-readable form, since long-term availability of tools to read any particular machine-readable format is an issue. If you use text in an OCR-friendly font, the human readable format and the machine readable format can be the same.
Apparently, this is a 2D barcode, with the hex version printed alongside it, so it fulfills both.
Oh, true, but that's not particularly worse than downloading random executables from the Internet. It's also relatively easy to suggest dangerous GUI operations, also, including digging in seemingly-innocent registry settings.
That's why it's important to have a solid community. I don't know how often people try it, but I do know that you won't find rm -rf / on the Ubuntu community forums.
But really, copying and pasting a random command from medibuntu.org is no more dangerous than downloading the k-lite codec pack from free-codecs.com -- and probably considerably less. That said, it would be nice if they provided a.deb which set up the repository for you, similar to how the Google Chrome package works.
When the OS is done right, you never have to do go under the hood.
The same is true of cars, which is where you're getting that analogy from. Nonetheless, we tend not to weld the hoods shut, and we also tend to expect that at some point, either we're going to have to get our hands dirty, or we're going to have to find someone else who can.
Most people know how to jump start, at least.
Just count all the official forum posts that a search google search on sound problems will bring up. Do it on for any linux distro out there at all, and THEN do it for apple.com.
Or you could search only on Ubuntu.com, to make that a fair comparison. I've had Mac problems where a keyboard setting erased itself every boot. I reported the bug, and a year later, it still hadn't been touched. How trivial would that be to fix?
To even the playing field, since you're going to say "waah! closed drivers, closed OS, proprietary hardware controlled by a single company!" then do yourself a favor and do the same for windows.
Thanks for putting words in my mouth.
In fact, Apple is generally more proprietary than Microsoft, with a few exceptions. Just compare the iPhone to Windows Mobile. On one of them, I can purchase and download apps from anywhere; on the other, I have to use the official App Store.
People go through wizards, control panels, setting dialogs and snappins. There's a pretty helpful device manager listing your hardware
Yeah, modern Linux distros do that also.
no need for lspci-level troubleshooting for most tasks.
That's because there's no equivalent to lspci on Windows. Last I checked, all I'm going to get in that Device Manager is a big yellow question mark for "Unknown Device" until I download a driver. But how do I know what the right driver is? The standard Windows approach would be to crack the case and look at the hardware, see if I see anything I recognize. My approach is to boot a Linux livecd, precisely so I can run lspci, save that to a text file, and read it from Notepad on Windows.
Need to find if 3d is supported? Run dxdiag.exe from the Start \ Run option.
facepalm
Do you not see the irony here? Start->Run IS A COMMANDLINE INTERFACE. It runs commands pretty much the same way you'd run them by opening a Command Prompt.
Linux has that, too. It's called alt+f2.
No need for a ps -e command --There's a task manager.
Have you even touched a Linux distro made in the last five years?
On my Kubuntu, the task manager is ctrl+esc. I like top, and tend to use it instead, but that doesn't mean there's no GUI version.
You don't have to learn CD, COPY, VER and other commands to turn on your PC.
And now you're outright lying. I've never once used any of these commands, unless you count 'cd' (that's right, it's lowercase), and never once needed them to turn on my PC.
A lot of distros provide GUI tools to help overcome our overreliance on the CLI, but they are not standard.
Waah, there's other options!
Use Ubuntu. There's your standard.
Don't like that I just told you to use one distro? Then show me where you have the choice of any other distros of Windows.
they won't stay if they are forced to learn a CLI that other OS's aren't forcing on them at all.
We are not asking them to learn the CLI.
We are asking them to copy and fucking paste. Just like Windows does when you tell them to paste dixdiag into the run dialog. It just happens to be way more efficient, both for them and for us, to paste one giant chunk of text into a terminal than to try to walk them through fifteen mouse clicks, each of which they can screw up.
the only reason terminal/copy/paste is a fail is that the vast majority of the computer-using public has spent the last twenty-plus years operating in GUI environments without them....
Without terminals, or without copy and paste?
That's the problem I'm having here. WTF is so scary about white text on a black background (or vice versa) that otherwise-intelligent people will seize up and lose all mental function, instead of ignoring the text and just choosing Edit->Paste, which can be done with the mouse?
I use various flavors of Linux and such at work, but a co-worker who is in no way mentally deficient absolutely refuses to even try...he's not mentally deficient, but he's been unduly affected by the memes about the difficulty of the CLI, and that colors his outlook sufficient to prevent CLI-OSes from making inroads.
I agree with the AC -- that kind of prejudice is a mental deficiency. Possibly an additional one on your part if you've continued to let him think that Linux is a "CLI-OS", any more than Windows is. The absolute most you would ever have to do as a user is, again, copy and paste -- and everything, including that copying and pasting, should be possible in a GUI with a mouse.
No, really, I don't. I get why expecting them to type commands into a terminal is a fail. I get why expecting them to ctrl+alt+f1 if their X screws up is a fail. I get why asking them to edit x.org when their video doesn't work is a fail. I understand why many things that are easy for me might not be easy for others.
But I don't get what's so difficult about opening a terminal and copying and fucking pasting. Don't they cover that in the "This is your mouse. Pushing this button is called 'clicking'" course? And after that, you might have to press enter. Ooh, scary.
I get that it's something we should avoid if possible. But I don't get why of all the possible things you could be bitching about, this is the usability problem that it's critical for Ubuntu to address -- people who can't copy and paste?
there is NO reason for them to copy paste and open a terminal. that can be written as a simple one click, enter password, done procedure.
The obvious reason for not doing that is that then Ubuntu would have to acknowledge Medibuntu.
Now, maybe the fault is with Medibuntu, in that Google seems to have no problem performing similar system-level modifications with one clickable deb to install Google Chrome. However, asking Ubuntu to "just put it on the desktop" is something you should really take up with the tools who voted for the DMCA -- there's not a lot Ubuntu can do about it.
Reccently I had a lay person rightly point out the danger of entering a root password everywhere for otherwise trivial administrative tasks (She had called me because she didn't want to enter the root password... just to download a update).
Actually, there's a good reason for that. If the admin knows what they're doing, it's trivial to enable updates to not require a password (root or otherwise -- you're probably thinking sudo password). Otherwise, you probably want updates to require explicit admin action -- this is why large organizations run Windows Updates through their own servers, so they can control exactly when to apply updates.
As an example, my mother runs an older version of Ubuntu, because it has an older (pre-2.0) version of Amarok -- you know, before Amarok started to suck. She knows updates are good, and she also knows not to do a full upgrade to a new version of Ubuntu (which would simultaneously upgrade Amarok). That's what I'm talking about -- there's no reason any fried who borrows her computer to do some web browsing should be able to fuck that up.
I understand the reasoning behind not including the drivers, but not including a icon on the desktop that is a "click here to download, install and enable the nvidia non free closed source evil drivers." is a must have.
Wait, what? Doesn't Ubuntu do this already?...I thought Ubuntu even enabled those drivers already.
Also the mediabuntu repository while easy for us that are familiar with ubuntu to reinstall at every release are near impossible for a newbie to install.
Really?
Open Terminal. Copy-and-paste from the website to the terminal. Enter password, press enter. Done.
Sure, it could be easier -- though I think Ubuntu tends to just put those in "multiverse" or something, and I wonder if medibuntu might be depricated by now.
I did mean that a single person could probably come up with a rough sketch, and that it wouldn't take much more to put it into action.
Now, you're probably right, and I'm probably underestimating the amount of effort, but I would take it a step further -- I'd say any billionaire could assemble such a team.
You clearly missed most of my post. Go back and read it again.
VMware and other tools do this by stuffing the entire system into a virtual machine, which is very likely to kill your video performance, at the very least. The only ones I know of which do 3D at all are restricted to OpenGL, or emulating Direct3D on top of GL -- these are targeted at Mac and Linux gamers wanting to run Windows games at full speed. I'm not sure if they can save state.
Regardless, it's still a huge amount of RAM to save, it means you can't update the game, it means if the game gets into an unstable state, you're SOL, and it means other apps within the VM are going to see weirdness. It means when something goes wrong with Windows in that VM, you're not going to be able to try the standard Windows approach of rebooting, because that would wipe your savegame.
It also means you'd have to disable the DRM anyway, because otherwise it's going to notice it's not connected to the Ubi servers and immediately drop you out of the game.
And it also means you just spent more money to buy a 64-bit Linux box with 16 or so gigs of RAM to play the game at a lower framerate, lower resolution, lower quality, than you'd get if you just bought the game.
I suppose it's theoretically possible, but it's about the last route I'd choose. The game already has a much safer and saner savegame feature built-in, it just needs to be liberated from the server requirement.
Actually, it might be easier, I'm just not sure. The local server would likely be a hybrid solution -- modify the game itself to perform fewer checks, and build a server which can handle saving files.
But if you're already modifying the game to isolate which communications involve saving a game, maybe it would be simpler just to dump it...
I suppose it depends how it saves games. If it just dumps all state over the wire, sure, easier to flush straight to disk. If it dumps some sort of delta, it might be easier to write a local server.
First, emulated games have access to the entire state in RAM. So, save the RAM and the framebuffer, then restore -- easy. This one is also going to have tons of state in video RAM, meaning you now have to re-initialize the entire DirectX (or OpenGL) context and load everything relevant there.
Second, emulated games assume a console, which is vastly simpler than an OS. Anywhere this game is accessing something in the OS, Internet, whatever, is a potential problem when restoring.
And finally, it means dumping all of the RAM, rather than the most convenient on-disk representation of RAM. That means savegames are now going to be several gigabytes of crap, instead of a few kilobytes.
And of course, as you say, if you update the game, it will cause problems -- I would say fatal problems. I don't see how you could reasonably expect to restore an old savegame to a patched game this way. With an emulator, you generally assume there isn't going to be a new patch to, say, Mario 64, and if you patch the emulator itself, it really doesn't matter, since the emulator knows how to dump the state of the emulated machine, not just a RAM image of the entire emulator. If there was a patch to the game itself, emulators wouldn't save you.
Recall that everything else about the server is DRM, which could easily be sliced out of the client, just as we've been doing for ages. The only tricky part is that all of the savegame logic assumes a server -- so the obvious solution there is to write just enough of a local server to handle the savegame.
So in other words, this is a combination of TFA's points 1 and 3, plus the fact that point 1 was assuming an actual hacker-run server, rather than something at 127.0.0.1. Possible, and probably not terribly difficult, for any group which has done this before.
In his edited version, he claims you can't play the "real" WoW, only some "cobbled-together emulation server". But this is fundamentally a single-player game. All the ingredients you need are local. The only part that would be "cobbled-together" is the part that allows you to save your game, and face it, that doesn't take nearly as much to get right. The fact that people have made cobbled-together WoW servers, a much harder task, shows that it's possible.
The final suggestion was to put more and more logic server-side. That's more and more of an investment on Ubi's part, in bandwidth and in server horsepower, and fewer and fewer people who can reliably play the game, given the number of low-bandwidth and unreliable Internet connections out there. I don't think they want to go that way.
It's a very difficult and expensive procedure, and you still end up with a lot of weapons grade fissionable material, which is a lot easier to steal when it's not part of a weapon.
Easier to steal, maybe, but you then still have to build a weapon. And wouldn't it be possible to put that to use, in, say, nuclear reactors?
If we give that away (and I hope we don't) then conventional forces become the deciding factor once again. That's not necessarily a good thing...
Not necessarily a bad thing, either.
The endgame of conventional weapons is conventional war, which is devastating and horrible, but survivable.
The endgame of nuclear weapons is MAD and nuclear winter, which would cause far more death and destruction, if, indeed, any humans survived at all.
MAD may be a less likely outcome, as it's less likely that either side would want to actually take that step -- but it's a risk I'd rather not take, if there's a choice. It's also not entirely impossible -- too many religions have an apocalypse story which sounds a lot like nukes.
It takes an entire people to build a civilization, to build something lasting... but only a fraction of that number to bring it all crashing down.
Think back to the root word of "Terrorism".
That fraction of that number can be a catalyst, yes. What determines whether or not it all comes crashing down is largely how we react. The Patriot Act was one of the greatest successes of terrorism -- they scared us so much that we gave away some of our most sacred liberties -- but they couldn't have done it without our help.
Now, nuclear weapons change that somewhat, but not a lot. There's still a fair amount of raw materials and resources needed, so you still need a fair number of people cooperating, usually at least one government. The biggest fear right now is that a terrorist will steal a nuclear weapon from an otherwise-peaceful country -- and the obvious response is, dismantle the nukes.
I don't think we are doing a great job of that lately. We are losing our friendly face and honor with the collateral damage from every well-intended military action we take.
Still, I don't think an appropriate response is to make it worse.
Terrorists are not human, they are unfathomably evil beings from hell and we cannot ever talk to or try to understand them.
I think you're being sarcastic... well, I hope...
Besides which, it's not just the terrorists, it's the people. If Iran were really a nation of terrorists -- if every single person in Iran was a terrorist -- we'd all be dead by now.
How about we also commission Google to shutdown services wherever we feel science and technology growth threatens our national security?
Unfortunately, that would also shut down the kind of communication which would be needed to encourage those places to stop being a threat to our national security.
Essentially, we can't keep people from being able to build nukes. It's a fundamental property of the Universe that matter can be converted to energy, and the design is obvious enough. The best we can do is try to keep the raw materials out of reach of the actual lunatics, and try to persuade the general population to play nice with us.
Perhaps I was too hasty, but both are still essentially correct.
First, you haven't found a bunny in the Cambrian. You've found some layers out of order, in -- surprise, surprise -- an area with a lot of geological activity. You've also found a number of other things, and you refuse to single one out for me to investigate, basically claiming all of them are true unless I can disprove them all.
Second, did you really expect that it would go that way, literally? That you'd pull a bunny out of the ground and it would all come crashing down instantly? No, of course there would be questions. You'd be asked to submit said bunny fossil to rigorous analysis, proving its age through a variety of tests; the site would probably be thoroughly investigated, to make sure you didn't just plant it there; serious questions would be raised about whether it is, in fact, a Bunny, and people would attempt to explain it via evolution; many scientists would probably withhold judgement until other, similar fossil bunnies could be found.
But at the end of it, you'd likely get a Nobel Prize.
I would've assumed this would be obvious and implicit, given that science generally doesn't reject long-held theories based on the first evidence to the contrary. The first helium balloon didn't instantly make us abandon our theory of gravity. I will attempt to be more explicit in the future.
But I have to ask... Why are you so afraid of attacking the simplest argument I've made, the one which involves no actual science or evidence, merely a simple, logical, philosophical thought experiment? Why do you have no answer to why Justnowism is false, but Creation is true?
You also need more boilerplate code to find alternatives if a feature *isn't* supposed by the card, which is something DirectX will do for you automatically.
In other words, DirectX provides more as a library. But we knew this already.
This means that you're forced to release your source (even the code produced by the Javascript compressors is legible enough for determined people).
Meh -- your binary code is readable with a disassembler, so that, too, is legible enough for determined people.
At the very least, it should (one would hope) lead to a genre of games which don't trust the client that much. As an example, this is the platform Second Life should've been developed in. (It also should've been as multi-server as email and the Web itself, but that's another issue.)
So you've making several mistakes here. First, you're assuming that I'm the one who originally claimed (or implied) anything at all in this thread, which I'm not (just look at the usernames). Second, even if I did say "Vista sucks," why would you ever assume that I think everything about Vista is bad? There are even things to like about Windows ME.
You can't test a future callsite when you write your code now, especially when it may be someone else doing it.
No, but you can test that future callsite when you write it. If you do need to change the behavior of the code in question, you have (hopefully) a comprehensive test suite of all the behavior you already expect. So you're testing at a high level, but that's what you really care about anyway, that whatever you changed or fixed, it didn't break the behavior at a high level.
Yes, you can throw a runtime error, but then the same guy who used your interface incorrectly ALSO has to handle an exception correctly,
Nope, if we're talking about the same thing -- a potential type error -- then an exception is fatal. You don't want that exception to ever happen in live code. Your test suite will handle reporting what caused that exception, and again, if it's not triggered during testing, either it works or your tests are incomplete.
I don't want someone accidentally sending an object representing the database table of employees to the network.Serialize() method because they used a CamelCase variable name instead of an lower_underscores somewhere.
I'm curious how that could actually happen -- I can't remember ever seeing issues like that.
I don't want the validity of MY code depending on someone else implementing their tests perfectly,
Well, it's still you writing tests. If you're writing an entirely standalone library, then yes, you'd test at a lower level -- but in the real world, you don't develop libraries in a vacuum. Even if you do have separate tests for the libraries, if you've done your job right, the tests appear as clear specifications of what the library expects -- and if someone tries to do something unusual, it's their job to make sure it works.
Let me turn it around -- to what extent do you trust your libraries and other tools to behave as expected? Say you're writing a database-driven web app -- doesn't it make sense to have at least some tests that work with both a real database and a real web request, so as to test the entire stack you've put together? Or would you take pains to isolate your code from platform and library code, thus ensuring your tests are the farthest thing imaginable from the real environment it runs in?
Slashdot Mirror
It'll take forever at first, but yes. Modern backup solutions would tend to be smarter still -- triggering automatically and silently in the background, sending deltas as soon as anything changes -- though presumably you could restrict how much bandwidth and what hours it would operate.
You can store USB keys in a safe. They're relatively cheap. They have no potential to be used as a gaming machine.
If you use the standalone computer for anything but storing the key,
Same problem occurs if I write doodles on the paper -- though I fail to see how that reduces the security, only the reliability.
or fail to physically secure the standalone computer from access
Granted, it's easier to secure a piece of paper. But the same problem applies.
More importantly, a closer analog to the paper is a USB thumb drive, which will fit just as neatly in a safety deposit box, or in your pocket, or (apparently) in your digestive system. It has flaws, but these would seem to be the exact same flaws the paper does -- for example, any machine on which I decrypt the data is necessarily a machine which will hold that key in RAM at some point, which means it's a point of failure.
The most paranoid solution I know of in that vein, which I used for awhile, is to boot off a thumb drive (which has the stored keys) and use full-disk encryption on the hard drive. I'd be pwned if and only if someone implements a BIOS-level or hardware-level exploit, and somehow does it without me noticing -- I kept a pretty close eye on that machine, physically. (Tempest would probably work, but you're not going to be left alone with it for long enough to do anything -- best case, you steal it, but then you don't have the USB key in my pocket.)
I stopped doing that when the USB key died, suddenly and completely, leaving me no way of accessing my data -- and my new laptop has an SSD, which is actually fast enough that crypto speed might be a limiting factor, whereas it definitely won't be on a 5400 RPM drive with any sort of modern CPU.
will likely be more likely to be practically usable to access data a longer time into the future.
Possible. We know a lot more about how paper degrades than we do about how data degrades (yet).
Though in this case, a key factor is making sure the paper has the key in a human-readable form as well as a machine-readable form, since long-term availability of tools to read any particular machine-readable format is an issue. If you use text in an OCR-friendly font, the human readable format and the machine readable format can be the same.
Apparently, this is a 2D barcode, with the hex version printed alongside it, so it fulfills both.
Oh, true, but that's not particularly worse than downloading random executables from the Internet. It's also relatively easy to suggest dangerous GUI operations, also, including digging in seemingly-innocent registry settings.
That's why it's important to have a solid community. I don't know how often people try it, but I do know that you won't find rm -rf / on the Ubuntu community forums.
But really, copying and pasting a random command from medibuntu.org is no more dangerous than downloading the k-lite codec pack from free-codecs.com -- and probably considerably less. That said, it would be nice if they provided a .deb which set up the repository for you, similar to how the Google Chrome package works.
When the OS is done right, you never have to do go under the hood.
The same is true of cars, which is where you're getting that analogy from. Nonetheless, we tend not to weld the hoods shut, and we also tend to expect that at some point, either we're going to have to get our hands dirty, or we're going to have to find someone else who can.
Most people know how to jump start, at least.
Just count all the official forum posts that a search google search on sound problems will bring up. Do it on for any linux distro out there at all, and THEN do it for apple.com.
Or you could search only on Ubuntu.com, to make that a fair comparison. I've had Mac problems where a keyboard setting erased itself every boot. I reported the bug, and a year later, it still hadn't been touched. How trivial would that be to fix?
To even the playing field, since you're going to say "waah! closed drivers, closed OS, proprietary hardware controlled by a single company!" then do yourself a favor and do the same for windows.
Thanks for putting words in my mouth.
In fact, Apple is generally more proprietary than Microsoft, with a few exceptions. Just compare the iPhone to Windows Mobile. On one of them, I can purchase and download apps from anywhere; on the other, I have to use the official App Store.
People go through wizards, control panels, setting dialogs and snappins. There's a pretty helpful device manager listing your hardware
Yeah, modern Linux distros do that also.
no need for lspci-level troubleshooting for most tasks.
That's because there's no equivalent to lspci on Windows. Last I checked, all I'm going to get in that Device Manager is a big yellow question mark for "Unknown Device" until I download a driver. But how do I know what the right driver is? The standard Windows approach would be to crack the case and look at the hardware, see if I see anything I recognize. My approach is to boot a Linux livecd, precisely so I can run lspci, save that to a text file, and read it from Notepad on Windows.
Need to find if 3d is supported? Run dxdiag.exe from the Start \ Run option.
facepalm
Do you not see the irony here? Start->Run IS A COMMANDLINE INTERFACE. It runs commands pretty much the same way you'd run them by opening a Command Prompt.
Linux has that, too. It's called alt+f2.
No need for a ps -e command --There's a task manager.
Have you even touched a Linux distro made in the last five years?
On my Kubuntu, the task manager is ctrl+esc. I like top, and tend to use it instead, but that doesn't mean there's no GUI version.
You don't have to learn CD, COPY, VER and other commands to turn on your PC.
And now you're outright lying. I've never once used any of these commands, unless you count 'cd' (that's right, it's lowercase), and never once needed them to turn on my PC.
A lot of distros provide GUI tools to help overcome our overreliance on the CLI, but they are not standard.
Waah, there's other options!
Use Ubuntu. There's your standard.
Don't like that I just told you to use one distro? Then show me where you have the choice of any other distros of Windows.
they won't stay if they are forced to learn a CLI that other OS's aren't forcing on them at all.
We are not asking them to learn the CLI.
We are asking them to copy and fucking paste. Just like Windows does when you tell them to paste dixdiag into the run dialog. It just happens to be way more efficient, both for them and for us, to paste one giant chunk of text into a terminal than to try to walk them through fifteen mouse clicks, each of which they can screw up.
Remember what th
the only reason terminal/copy/paste is a fail is that the vast majority of the computer-using public has spent the last twenty-plus years operating in GUI environments without them....
Without terminals, or without copy and paste?
That's the problem I'm having here. WTF is so scary about white text on a black background (or vice versa) that otherwise-intelligent people will seize up and lose all mental function, instead of ignoring the text and just choosing Edit->Paste, which can be done with the mouse?
I use various flavors of Linux and such at work, but a co-worker who is in no way mentally deficient absolutely refuses to even try...he's not mentally deficient, but he's been unduly affected by the memes about the difficulty of the CLI, and that colors his outlook sufficient to prevent CLI-OSes from making inroads.
I agree with the AC -- that kind of prejudice is a mental deficiency. Possibly an additional one on your part if you've continued to let him think that Linux is a "CLI-OS", any more than Windows is. The absolute most you would ever have to do as a user is, again, copy and paste -- and everything, including that copying and pasting, should be possible in a GUI with a mouse.
for non Unix people... it's an EPIC fail.
I don't get it.
No, really, I don't. I get why expecting them to type commands into a terminal is a fail. I get why expecting them to ctrl+alt+f1 if their X screws up is a fail. I get why asking them to edit x.org when their video doesn't work is a fail. I understand why many things that are easy for me might not be easy for others.
But I don't get what's so difficult about opening a terminal and copying and fucking pasting. Don't they cover that in the "This is your mouse. Pushing this button is called 'clicking'" course? And after that, you might have to press enter. Ooh, scary.
I get that it's something we should avoid if possible. But I don't get why of all the possible things you could be bitching about, this is the usability problem that it's critical for Ubuntu to address -- people who can't copy and paste?
there is NO reason for them to copy paste and open a terminal. that can be written as a simple one click, enter password, done procedure.
The obvious reason for not doing that is that then Ubuntu would have to acknowledge Medibuntu.
Now, maybe the fault is with Medibuntu, in that Google seems to have no problem performing similar system-level modifications with one clickable deb to install Google Chrome. However, asking Ubuntu to "just put it on the desktop" is something you should really take up with the tools who voted for the DMCA -- there's not a lot Ubuntu can do about it.
Reccently I had a lay person rightly point out the danger of entering a root password everywhere for otherwise trivial administrative tasks (She had called me because she didn't want to enter the root password... just to download a update).
Actually, there's a good reason for that. If the admin knows what they're doing, it's trivial to enable updates to not require a password (root or otherwise -- you're probably thinking sudo password). Otherwise, you probably want updates to require explicit admin action -- this is why large organizations run Windows Updates through their own servers, so they can control exactly when to apply updates.
As an example, my mother runs an older version of Ubuntu, because it has an older (pre-2.0) version of Amarok -- you know, before Amarok started to suck. She knows updates are good, and she also knows not to do a full upgrade to a new version of Ubuntu (which would simultaneously upgrade Amarok). That's what I'm talking about -- there's no reason any fried who borrows her computer to do some web browsing should be able to fuck that up.
I understand the reasoning behind not including the drivers, but not including a icon on the desktop that is a "click here to download, install and enable the nvidia non free closed source evil drivers." is a must have.
Wait, what? Doesn't Ubuntu do this already? ...I thought Ubuntu even enabled those drivers already.
Also the mediabuntu repository while easy for us that are familiar with ubuntu to reinstall at every release are near impossible for a newbie to install.
Really?
Open Terminal. Copy-and-paste from the website to the terminal. Enter password, press enter. Done.
Sure, it could be easier -- though I think Ubuntu tends to just put those in "multiverse" or something, and I wonder if medibuntu might be depricated by now.
I did mean that a single person could probably come up with a rough sketch, and that it wouldn't take much more to put it into action.
Now, you're probably right, and I'm probably underestimating the amount of effort, but I would take it a step further -- I'd say any billionaire could assemble such a team.
VMware and some other tools do this quite nicely,
*facepalm*
You clearly missed most of my post. Go back and read it again.
VMware and other tools do this by stuffing the entire system into a virtual machine, which is very likely to kill your video performance, at the very least. The only ones I know of which do 3D at all are restricted to OpenGL, or emulating Direct3D on top of GL -- these are targeted at Mac and Linux gamers wanting to run Windows games at full speed. I'm not sure if they can save state.
Regardless, it's still a huge amount of RAM to save, it means you can't update the game, it means if the game gets into an unstable state, you're SOL, and it means other apps within the VM are going to see weirdness. It means when something goes wrong with Windows in that VM, you're not going to be able to try the standard Windows approach of rebooting, because that would wipe your savegame.
It also means you'd have to disable the DRM anyway, because otherwise it's going to notice it's not connected to the Ubi servers and immediately drop you out of the game.
And it also means you just spent more money to buy a 64-bit Linux box with 16 or so gigs of RAM to play the game at a lower framerate, lower resolution, lower quality, than you'd get if you just bought the game.
I suppose it's theoretically possible, but it's about the last route I'd choose. The game already has a much safer and saner savegame feature built-in, it just needs to be liberated from the server requirement.
Actually, it might be easier, I'm just not sure. The local server would likely be a hybrid solution -- modify the game itself to perform fewer checks, and build a server which can handle saving files.
But if you're already modifying the game to isolate which communications involve saving a game, maybe it would be simpler just to dump it...
I suppose it depends how it saves games. If it just dumps all state over the wire, sure, easier to flush straight to disk. If it dumps some sort of delta, it might be easier to write a local server.
That is harder to do.
First, emulated games have access to the entire state in RAM. So, save the RAM and the framebuffer, then restore -- easy. This one is also going to have tons of state in video RAM, meaning you now have to re-initialize the entire DirectX (or OpenGL) context and load everything relevant there.
Second, emulated games assume a console, which is vastly simpler than an OS. Anywhere this game is accessing something in the OS, Internet, whatever, is a potential problem when restoring.
And finally, it means dumping all of the RAM, rather than the most convenient on-disk representation of RAM. That means savegames are now going to be several gigabytes of crap, instead of a few kilobytes.
And of course, as you say, if you update the game, it will cause problems -- I would say fatal problems. I don't see how you could reasonably expect to restore an old savegame to a patched game this way. With an emulator, you generally assume there isn't going to be a new patch to, say, Mario 64, and if you patch the emulator itself, it really doesn't matter, since the emulator knows how to dump the state of the emulated machine, not just a RAM image of the entire emulator. If there was a patch to the game itself, emulators wouldn't save you.
Doubtful.
Recall that everything else about the server is DRM, which could easily be sliced out of the client, just as we've been doing for ages. The only tricky part is that all of the savegame logic assumes a server -- so the obvious solution there is to write just enough of a local server to handle the savegame.
So in other words, this is a combination of TFA's points 1 and 3, plus the fact that point 1 was assuming an actual hacker-run server, rather than something at 127.0.0.1. Possible, and probably not terribly difficult, for any group which has done this before.
In his edited version, he claims you can't play the "real" WoW, only some "cobbled-together emulation server". But this is fundamentally a single-player game. All the ingredients you need are local. The only part that would be "cobbled-together" is the part that allows you to save your game, and face it, that doesn't take nearly as much to get right. The fact that people have made cobbled-together WoW servers, a much harder task, shows that it's possible.
The final suggestion was to put more and more logic server-side. That's more and more of an investment on Ubi's part, in bandwidth and in server horsepower, and fewer and fewer people who can reliably play the game, given the number of low-bandwidth and unreliable Internet connections out there. I don't think they want to go that way.
It's a very difficult and expensive procedure, and you still end up with a lot of weapons grade fissionable material, which is a lot easier to steal when it's not part of a weapon.
Easier to steal, maybe, but you then still have to build a weapon. And wouldn't it be possible to put that to use, in, say, nuclear reactors?
If we give that away (and I hope we don't) then conventional forces become the deciding factor once again. That's not necessarily a good thing...
Not necessarily a bad thing, either.
The endgame of conventional weapons is conventional war, which is devastating and horrible, but survivable.
The endgame of nuclear weapons is MAD and nuclear winter, which would cause far more death and destruction, if, indeed, any humans survived at all.
MAD may be a less likely outcome, as it's less likely that either side would want to actually take that step -- but it's a risk I'd rather not take, if there's a choice. It's also not entirely impossible -- too many religions have an apocalypse story which sounds a lot like nukes.
It takes an entire people to build a civilization, to build something lasting ... but only a fraction of that number to bring it all crashing down.
Think back to the root word of "Terrorism".
That fraction of that number can be a catalyst, yes. What determines whether or not it all comes crashing down is largely how we react. The Patriot Act was one of the greatest successes of terrorism -- they scared us so much that we gave away some of our most sacred liberties -- but they couldn't have done it without our help.
Now, nuclear weapons change that somewhat, but not a lot. There's still a fair amount of raw materials and resources needed, so you still need a fair number of people cooperating, usually at least one government. The biggest fear right now is that a terrorist will steal a nuclear weapon from an otherwise-peaceful country -- and the obvious response is, dismantle the nukes.
I don't think we are doing a great job of that lately. We are losing our friendly face and honor with the collateral damage from every well-intended military action we take.
Still, I don't think an appropriate response is to make it worse.
Terrorists are not human, they are unfathomably evil beings from hell and we cannot ever talk to or try to understand them.
I think you're being sarcastic... well, I hope...
Besides which, it's not just the terrorists, it's the people. If Iran were really a nation of terrorists -- if every single person in Iran was a terrorist -- we'd all be dead by now.
How about we also commission Google to shutdown services wherever we feel science and technology growth threatens our national security?
Unfortunately, that would also shut down the kind of communication which would be needed to encourage those places to stop being a threat to our national security.
Essentially, we can't keep people from being able to build nukes. It's a fundamental property of the Universe that matter can be converted to energy, and the design is obvious enough. The best we can do is try to keep the raw materials out of reach of the actual lunatics, and try to persuade the general population to play nice with us.
Perhaps I was too hasty, but both are still essentially correct.
First, you haven't found a bunny in the Cambrian. You've found some layers out of order, in -- surprise, surprise -- an area with a lot of geological activity. You've also found a number of other things, and you refuse to single one out for me to investigate, basically claiming all of them are true unless I can disprove them all.
Second, did you really expect that it would go that way, literally? That you'd pull a bunny out of the ground and it would all come crashing down instantly? No, of course there would be questions. You'd be asked to submit said bunny fossil to rigorous analysis, proving its age through a variety of tests; the site would probably be thoroughly investigated, to make sure you didn't just plant it there; serious questions would be raised about whether it is, in fact, a Bunny, and people would attempt to explain it via evolution; many scientists would probably withhold judgement until other, similar fossil bunnies could be found.
But at the end of it, you'd likely get a Nobel Prize.
I would've assumed this would be obvious and implicit, given that science generally doesn't reject long-held theories based on the first evidence to the contrary. The first helium balloon didn't instantly make us abandon our theory of gravity. I will attempt to be more explicit in the future.
But I have to ask... Why are you so afraid of attacking the simplest argument I've made, the one which involves no actual science or evidence, merely a simple, logical, philosophical thought experiment? Why do you have no answer to why Justnowism is false, but Creation is true?
You also need more boilerplate code to find alternatives if a feature *isn't* supposed by the card, which is something DirectX will do for you automatically.
In other words, DirectX provides more as a library. But we knew this already.
This means that you're forced to release your source (even the code produced by the Javascript compressors is legible enough for determined people).
Meh -- your binary code is readable with a disassembler, so that, too, is legible enough for determined people.
At the very least, it should (one would hope) lead to a genre of games which don't trust the client that much. As an example, this is the platform Second Life should've been developed in. (It also should've been as multi-server as email and the Web itself, but that's another issue.)
suffers from being controlled by Javascript and thus is slower in everything that's not Chrome
Not exactly Google's fault, and other browsers are getting better.
The sooner we have Canvas 3D contexts though the better
Doesn't WebGL do exactly that?
Read more carefully, that's all I can say.
Well, and write more carefully:
You just infer the fact,
The word you're probably looking for is "imply".
So you've making several mistakes here. First, you're assuming that I'm the one who originally claimed (or implied) anything at all in this thread, which I'm not (just look at the usernames). Second, even if I did say "Vista sucks," why would you ever assume that I think everything about Vista is bad? There are even things to like about Windows ME.
You can't test a future callsite when you write your code now, especially when it may be someone else doing it.
No, but you can test that future callsite when you write it. If you do need to change the behavior of the code in question, you have (hopefully) a comprehensive test suite of all the behavior you already expect. So you're testing at a high level, but that's what you really care about anyway, that whatever you changed or fixed, it didn't break the behavior at a high level.
Yes, you can throw a runtime error, but then the same guy who used your interface incorrectly ALSO has to handle an exception correctly,
Nope, if we're talking about the same thing -- a potential type error -- then an exception is fatal. You don't want that exception to ever happen in live code. Your test suite will handle reporting what caused that exception, and again, if it's not triggered during testing, either it works or your tests are incomplete.
I don't want someone accidentally sending an object representing the database table of employees to the network.Serialize() method because they used a CamelCase variable name instead of an lower_underscores somewhere.
I'm curious how that could actually happen -- I can't remember ever seeing issues like that.
I don't want the validity of MY code depending on someone else implementing their tests perfectly,
Well, it's still you writing tests. If you're writing an entirely standalone library, then yes, you'd test at a lower level -- but in the real world, you don't develop libraries in a vacuum. Even if you do have separate tests for the libraries, if you've done your job right, the tests appear as clear specifications of what the library expects -- and if someone tries to do something unusual, it's their job to make sure it works.
Let me turn it around -- to what extent do you trust your libraries and other tools to behave as expected? Say you're writing a database-driven web app -- doesn't it make sense to have at least some tests that work with both a real database and a real web request, so as to test the entire stack you've put together? Or would you take pains to isolate your code from platform and library code, thus ensuring your tests are the farthest thing imaginable from the real environment it runs in?
That actually makes a lot of sense. Thanks!