The housing department wouldn't accept payments through the bursar's office, which is specifically set up to deal with large amounts of cash. So they'd just have to set up an account with the bursar (probably a fair bit of paperwork, but not an insane amount -- one person should be able to do it in a week), and Bob's your uncle. That's how my uni set it up.
Of course, the poster could simply go to the bank or post office and get a money order or a cashier's cheque and pay them. It's not *that* big a deal; it's only twice a year.
I have a vested interest in other people using Linux. The more people using it, the more likely it is that software will be released for it. Likewise with the Wii or PS3.
This doesn't hold for areas where the competition is mainly for implementation of an existing format. In those cases, you don't get nearly as much fanboyism for particular implementations. Also, you don't get as much fanboyism for the generic product. It seems to make sense intuitively, but I'd be interested to learn why that is.
I'm not sure what 'indiscriminate criticism' is. It sounds like libel or slander -- if there's a valid reason to criticize an entity, then such criticism is not indiscriminate. Or perhaps it's simply criticizing an entity without doing any fact checking.
In that case, it's wholly appropriate for a government funded institution to be forbidden from indiscriminate criticism of any entity.
The issue is that I don't see how the professor in question exercised indiscriminate criticism, or actually any criticism -- he simply linked to a site featuring criticism.
You can decompile the object code into C or C++ or whatever (in the case of C++, there will be template issues...). Then you can compare the results with the source you're given. If they don't match (variable names, file arrangements, comments etc notwithstanding), then you immediately invalidate the election results, start analyzing the decompiled code further, and start proceedings against the vendor for failure to comply.
Or, more simply, you demand an exact copy of the build system from the vendor, build the submitted sources on it, and check the MD5 sums against the sums from the voting machines. If they don't match, you start the same process.
But if you don't have the original sources, it's much harder to analyze anything.
I doubt MS is seriously worried about someone producing a Windows clone or forking its codebase; it would be too identifiable. With embedded Windows, there isn't any worry about finding a way around WGA. The real worry would be potential customers finding out how buggy and unreliable Windows code is, if it is in fact unreliable. (Note this is specifically about embedded Windows, not desktop Windows. Embedded Windows might be reliable; I haven't used it.)
Oh, of course there's a chance that some Taiwanese company will start selling embedded Windows products without licenses, but that's already a risk.
The only issue I see is revealing hidden APIs -- hidden either because they're dangerous to use or because they give Microsoft a competitive advantage. That and any bugs or security holes could be exploited that much quicker.
Actually, that's a good idea. A crazy and stupid idea, but one that would have good effects. If the electronic voting machines reported that the winner of the election was, say, Bilbo Baggins, then people would very quickly lose faith in them and switch back to mechanical voting machines.
Even so, there's a margin of error for mechanical voting machines that's a fair bit larger than the margin of victory in many elections. Though the electoral college limits this somewhat.
A physical voting system rather than an electronic one helps. The labels on the buttons aren't going to change if they're engraved, and they can directly mark a piece of paper to record the vote in a way that a user can observe and verify.
If there are enough people paying, there are probably enough points of view that a careful scientist can get funding regardless of the intent or results of the research, as long as it's on a popular topic.
Well, you can get a consensus via political maneuvering, or you can get it through plain debate and solid arguments backed by good, reproducible data. Meteorology doesn't strike me as a field where political actions are given much credit. Climatology more so, but still not by much.
Consider also that if you proved that global warming was entirely bogus, you'd probably be one of the most recognized climatologists of the era. Likewise with any widely trusted scientific theory. The more pressure there is to conform, the higher the rewards if you disprove the theory. Though of course you'll need better arguments and data than you would otherwise.
Unless the situation is such that the downloader has a reasonable expectation that their download is legitimate (e.g. they paid for it, or got it from a site claiming that the copyright holder approved of its availability). If Blockbuster started selling pirated films, nobody would think that the customers should be sued.
And unless the distributer has taken reasonable precautions against illegitimate access. If you hack into my sftp server and download my music, well, I certainly didn't give you my password. Your access would have been against my will, and I tried to prevent it, so no jury would convict me.
Except the stuff with the most polish, the most easily used stuff, the stuff that has a heavy UI component, that's all been heavily backed by corporations.
OpenOffice? Sun. GNOME? Novell and RedHat. KDE? TrollTech.
"To begin a work is divine; to complete it, servile." (Leonardo da Vinci) It takes an incentive such as a job to keep many developers working on a project once all the interesting bits are finished.
You just ship both on the resource CD and let the end user ignore the object files. It's embedded, so the end users won't be mucking about with it much, and the poster will be installing the software anyway.
But competitors are buying the box without the code, and they need the code. Releasing your code would then provide a leg up to your opponents. And then, due to their lower R&D costs, they can sell your product cheaper.
Better yet, UI studies from people who haven't used Linux before, the sort that will rely on the GUI and don't know much about fixing problems. Give half of them new Dells with Ubuntu on them, the other half new Dells with Windows on them. Compare their productivity at one day, one week, one month, three months, and six months.
A study like that with a reasonable number of people (probably twenty or thirty in each group) would have some weight to it. More than a Linux sysadmin installing Linux at home and liking it.
Gecko, XUL, networking, interface at the top level.
For testing, you can provide a dummy display and use local sockets for networking; that lets you test Gecko for memory usage (and also allows for automated unit testing). And you can provide a dummy renderer that just sends stuff in whatever format Gecko produces to test the display. And so forth.
After that, you're left with any weirdness that results from putting these well-tested components together. Any remaining errors will probably be difficult to find, though.
There are projects such as JUnit, NUnit, and RhinoMocks that help with this sort of thing.
Only to the extent that DRM software is released under GPLv3.
And regardless of when you exchange keys, the end user always ends up with a plaintext that's difficult to copy, an encrypted text that's easy to copy, and a key that may be difficult to locate. As long as end users control their software, DRM doesn't stand much of a chance. And that is why TiVo DRM has a better chance at being effective than any DRM system that works on a regular computer.
How do Alice and Bob agree on the strength of their respective resistors?
What you could do is randomize the resistance at each nonzero turn; this will allow you to mask any differences in the strength of your resistors (if Bob's resistor is a bit off and has 99.5% of Alice's, suddenly Eve can tell what data is going through). Alice and Bob can still tell if they're using baseline or non-baseline resistances and whether the other is, and they can tell whether the total resistance in the wire is greater than what they're providing.
Of course, with your system, let's up the paranoia by a few orders of magnitude. Alice and Bob use a one-time pad to control the resistance of their respective resistors. Well, now they have the pad; they may as well just use that, unless they're worried about someone recording the transmission and later finding the pad. This would only increase the difficulty slightly, not enough to really bother with.
This is an issue if you want to distribute LINA with your application, or at least a possible issue. Note the Classpath exception to the GPL which considers dynamic linking to produce a derivative work.
If this turns out to be a serious issue, we can write a wrapper around standard Qt with a compatible ABI/API so you can just use autotools, develop for multiple Linux distros, and then just test against LINA. Compile it on any Linux you want and deploy on LINA.
Then just use Tango icons and icon styles in your application (they look good, though they aren't colorful enough for KDE's typical style or cartoonish enough for OS X's typical style, but I doubt anyone will complain), and you can provide different icons relatively easily (since the install script has to muck about with the native OS).
You could come up with a small library that connects keyboard shortcuts appropriately according to the current OS and window manager. It'd be relatively simple.
You do get a performance hit, but who cares? It would add less than half a second to the startup time and would incur no cost afterward. If performance were that much of an issue, you'd be compiling natively in C or Fortran.
The issue is running an OpenGL game in a virtual machine. Unless that machine is quite intelligent about it, the graphics are going to go very slowly.
If the VM *is* clever, then you may start seeing Linux-native games using DirectX.
You could improve performance somewhat (a factor of three instead of a factor of ten, maybe) by making a client/server model in which VM applications act as OpenGL clients connecting to a native OpenGL server. You might be able to use memory mapping to improve the speed a bit more.
There are two aspects to the game: the data and the engine. The data is separately copyrighted. The engine is GPL, so any engine modifications must be published as source if they're published at all. So if you come up with an uber-cool stealth mod to Quake 3 and distribute it in your game, I can use the mod, but I don't have any more license to the textures, scripts, and world than you choose to give me.
You can have a viable commercial game released on an open source engine. You just have slightly less protection against clones of your game. But the bulk of it is the data, not the engine, even if the engine's harder.
Slashdot Mirror
The housing department wouldn't accept payments through the bursar's office, which is specifically set up to deal with large amounts of cash. So they'd just have to set up an account with the bursar (probably a fair bit of paperwork, but not an insane amount -- one person should be able to do it in a week), and Bob's your uncle. That's how my uni set it up.
Of course, the poster could simply go to the bank or post office and get a money order or a cashier's cheque and pay them. It's not *that* big a deal; it's only twice a year.
First time I've ever heard a slashdotter asking for a dupe.
I have a vested interest in other people using Linux. The more people using it, the more likely it is that software will be released for it. Likewise with the Wii or PS3.
This doesn't hold for areas where the competition is mainly for implementation of an existing format. In those cases, you don't get nearly as much fanboyism for particular implementations. Also, you don't get as much fanboyism for the generic product. It seems to make sense intuitively, but I'd be interested to learn why that is.
I'm not sure what 'indiscriminate criticism' is. It sounds like libel or slander -- if there's a valid reason to criticize an entity, then such criticism is not indiscriminate. Or perhaps it's simply criticizing an entity without doing any fact checking.
In that case, it's wholly appropriate for a government funded institution to be forbidden from indiscriminate criticism of any entity.
The issue is that I don't see how the professor in question exercised indiscriminate criticism, or actually any criticism -- he simply linked to a site featuring criticism.
You can decompile the object code into C or C++ or whatever (in the case of C++, there will be template issues...). Then you can compare the results with the source you're given. If they don't match (variable names, file arrangements, comments etc notwithstanding), then you immediately invalidate the election results, start analyzing the decompiled code further, and start proceedings against the vendor for failure to comply.
Or, more simply, you demand an exact copy of the build system from the vendor, build the submitted sources on it, and check the MD5 sums against the sums from the voting machines. If they don't match, you start the same process.
But if you don't have the original sources, it's much harder to analyze anything.
I doubt MS is seriously worried about someone producing a Windows clone or forking its codebase; it would be too identifiable. With embedded Windows, there isn't any worry about finding a way around WGA. The real worry would be potential customers finding out how buggy and unreliable Windows code is, if it is in fact unreliable. (Note this is specifically about embedded Windows, not desktop Windows. Embedded Windows might be reliable; I haven't used it.)
Oh, of course there's a chance that some Taiwanese company will start selling embedded Windows products without licenses, but that's already a risk.
The only issue I see is revealing hidden APIs -- hidden either because they're dangerous to use or because they give Microsoft a competitive advantage. That and any bugs or security holes could be exploited that much quicker.
Actually, that's a good idea. A crazy and stupid idea, but one that would have good effects. If the electronic voting machines reported that the winner of the election was, say, Bilbo Baggins, then people would very quickly lose faith in them and switch back to mechanical voting machines.
Even so, there's a margin of error for mechanical voting machines that's a fair bit larger than the margin of victory in many elections. Though the electoral college limits this somewhat.
A physical voting system rather than an electronic one helps. The labels on the buttons aren't going to change if they're engraved, and they can directly mark a piece of paper to record the vote in a way that a user can observe and verify.
If there are enough people paying, there are probably enough points of view that a careful scientist can get funding regardless of the intent or results of the research, as long as it's on a popular topic.
Well, you can get a consensus via political maneuvering, or you can get it through plain debate and solid arguments backed by good, reproducible data. Meteorology doesn't strike me as a field where political actions are given much credit. Climatology more so, but still not by much.
Consider also that if you proved that global warming was entirely bogus, you'd probably be one of the most recognized climatologists of the era. Likewise with any widely trusted scientific theory. The more pressure there is to conform, the higher the rewards if you disprove the theory. Though of course you'll need better arguments and data than you would otherwise.
Unless the situation is such that the downloader has a reasonable expectation that their download is legitimate (e.g. they paid for it, or got it from a site claiming that the copyright holder approved of its availability). If Blockbuster started selling pirated films, nobody would think that the customers should be sued.
And unless the distributer has taken reasonable precautions against illegitimate access. If you hack into my sftp server and download my music, well, I certainly didn't give you my password. Your access would have been against my will, and I tried to prevent it, so no jury would convict me.
Except the stuff with the most polish, the most easily used stuff, the stuff that has a heavy UI component, that's all been heavily backed by corporations.
OpenOffice? Sun.
GNOME? Novell and RedHat.
KDE? TrollTech.
"To begin a work is divine; to complete it, servile." (Leonardo da Vinci) It takes an incentive such as a job to keep many developers working on a project once all the interesting bits are finished.
You just ship both on the resource CD and let the end user ignore the object files. It's embedded, so the end users won't be mucking about with it much, and the poster will be installing the software anyway.
It's a non-issue.
But competitors are buying the box without the code, and they need the code. Releasing your code would then provide a leg up to your opponents. And then, due to their lower R&D costs, they can sell your product cheaper.
That sounds like a bandwidth hog. I wouldn't use that for Wikipedia, certainly, but maybe for Google.
The grandparent's point is that it would be trivial to modify Playfair to remove personally identifying information from files.
Better yet, UI studies from people who haven't used Linux before, the sort that will rely on the GUI and don't know much about fixing problems. Give half of them new Dells with Ubuntu on them, the other half new Dells with Windows on them. Compare their productivity at one day, one week, one month, three months, and six months.
A study like that with a reasonable number of people (probably twenty or thirty in each group) would have some weight to it. More than a Linux sysadmin installing Linux at home and liking it.
Gecko, XUL, networking, interface at the top level.
For testing, you can provide a dummy display and use local sockets for networking; that lets you test Gecko for memory usage (and also allows for automated unit testing). And you can provide a dummy renderer that just sends stuff in whatever format Gecko produces to test the display. And so forth.
After that, you're left with any weirdness that results from putting these well-tested components together. Any remaining errors will probably be difficult to find, though.
There are projects such as JUnit, NUnit, and RhinoMocks that help with this sort of thing.
Only to the extent that DRM software is released under GPLv3.
And regardless of when you exchange keys, the end user always ends up with a plaintext that's difficult to copy, an encrypted text that's easy to copy, and a key that may be difficult to locate. As long as end users control their software, DRM doesn't stand much of a chance. And that is why TiVo DRM has a better chance at being effective than any DRM system that works on a regular computer.
error: this will break the following dependencies: ...
bsod: is required by win-desktop
bsod: is required by win-gui
bsod: is required by nt-kernel
How do Alice and Bob agree on the strength of their respective resistors?
What you could do is randomize the resistance at each nonzero turn; this will allow you to mask any differences in the strength of your resistors (if Bob's resistor is a bit off and has 99.5% of Alice's, suddenly Eve can tell what data is going through). Alice and Bob can still tell if they're using baseline or non-baseline resistances and whether the other is, and they can tell whether the total resistance in the wire is greater than what they're providing.
Of course, with your system, let's up the paranoia by a few orders of magnitude. Alice and Bob use a one-time pad to control the resistance of their respective resistors. Well, now they have the pad; they may as well just use that, unless they're worried about someone recording the transmission and later finding the pad. This would only increase the difficulty slightly, not enough to really bother with.
This is an issue if you want to distribute LINA with your application, or at least a possible issue. Note the Classpath exception to the GPL which considers dynamic linking to produce a derivative work.
If this turns out to be a serious issue, we can write a wrapper around standard Qt with a compatible ABI/API so you can just use autotools, develop for multiple Linux distros, and then just test against LINA. Compile it on any Linux you want and deploy on LINA.
---
if (style == Style.Windows) {
preferences_menu_item.name = "Options";
add_menu_item(preferences_menu_item, tools_menu);
} else {
preferences_menu_item.name = "Preferences";
add_menu_item(preferences_menu_item, edit_menu);
}
---
Then just use Tango icons and icon styles in your application (they look good, though they aren't colorful enough for KDE's typical style or cartoonish enough for OS X's typical style, but I doubt anyone will complain), and you can provide different icons relatively easily (since the install script has to muck about with the native OS).
You could come up with a small library that connects keyboard shortcuts appropriately according to the current OS and window manager. It'd be relatively simple.
You do get a performance hit, but who cares? It would add less than half a second to the startup time and would incur no cost afterward. If performance were that much of an issue, you'd be compiling natively in C or Fortran.
The issue is running an OpenGL game in a virtual machine. Unless that machine is quite intelligent about it, the graphics are going to go very slowly.
If the VM *is* clever, then you may start seeing Linux-native games using DirectX.
You could improve performance somewhat (a factor of three instead of a factor of ten, maybe) by making a client/server model in which VM applications act as OpenGL clients connecting to a native OpenGL server. You might be able to use memory mapping to improve the speed a bit more.
There are two aspects to the game: the data and the engine. The data is separately copyrighted. The engine is GPL, so any engine modifications must be published as source if they're published at all. So if you come up with an uber-cool stealth mod to Quake 3 and distribute it in your game, I can use the mod, but I don't have any more license to the textures, scripts, and world than you choose to give me.
You can have a viable commercial game released on an open source engine. You just have slightly less protection against clones of your game. But the bulk of it is the data, not the engine, even if the engine's harder.