It's not only possible, it's easy. The main thing to watch is libraries. All you have to do is avoid using libraries available only under the GPL in your program. The only critical libraries that your program will have to use are glibc and the GCC C++ library module, and both of those are under LGPL-style licenses. As long as you dynamically link to them (so the library object code isn't physically included in your executable) you don't have a licensing problem. Other libraries you'll have to look at their license terms to see whether they're compatible and how you have to use them to be compatible, but none of those are required to run on Linux and you can just not use them if you can't find a way to be compatible with their licenses. GTK (Gnome) and Qt (KDE) are probably highly desirable for GUI apps, but GTK's under the LGPL and Qt has a commercial license available so you can use both without having to open-source your code.
I'm not sure why companies would need any special outline for Linux. That it's open-source is irrelevant for most software, really. If you're making a kernel module the issue comes into play, but very few things other than actual hardware devices need kernel modules. If you include GPL'd libraries in your software there's a licensing issue, but then if you include any libraries licensed from third parties you've got a licensing issue when you start distributing them and you're going to have to do some negotiating and cough up some money. I don't think there's any GPL'd libraries that apps on Linux have to use, so any app should be able to avoid the issue if they want to. The only thing left is integration into the system:
Installation of the software. Not much to say here. A simple tar file that can be unpacked and copied under/usr/local, or that's got an installation script that does the work, should work on any Unix out there including Linux. At worst you've got to add a library directory to/etc/ld.so.conf, but usually a small wrapper script that sets LD_LIBRARY_PATH appropriately obviates the need for that. If you want to use the native packaging system you've got to build binary packages, but that's usually straightforward and covered in the documentation for each distro.
Integration into the system startup scripts. There's a couple of different layouts for the startup script directories, and each distro has it's own little customizations you have to accomodate for perfect integration (things like how the script should check for the software already being started during runlevel changes, stuff like that). But how much software really needs to be set running during startup? Most doesn't, but the few packages that do have some complexity on their hands.
Desktop integration. This isn't a Linux issue, it's a Gnome and KDE issue (those being the two major ones these days). Their Web sites have guides on how to do this right IIRC, and if you follow them it should work for that desktop on any platform the desktop runs on. Linux is simply another platform.
Integration with the desktop. Um, this is Unix. There is no single desktop. Any user on the system can run any desktop, and in fact run different desktops at different times. Best bet is to follow the guides for integration, check for each desktop and integrate with all that're installed, and provide a single executable (or a wrapper script) that a user can run from the command line that'll start your app. That last insures users can use your app without any desktop integration at all by simply manually creating a launcher for it where they want one.
Copy protection. This can be an issue. The world outside Windows is remarkably hostile to the sorts of copy-protection schemes seen in Windows software, and Linux isn't unique in this. License key servers can be used, but they tend to cause more headaches for your customers (even when working properly) than for pirates. Hardware keying is a pain since Unixes tend to hide the hardware so well the detailed information isn't readily available (you can get it, but it takes a fair amount of hackery).
Have I missed anything? I don't think I have, and aside from the issue of copy protection none of the above needs any special communication or coordination between the software vendor and the Linux community or distributions to deal with beyond reading the relevant docs. Maybe it's that the vendors have a problem believing it can be that simple after all these years of dealing with the complexities of Windows?
There really isn't any. The only one Diebold &co have come up with is "The printers aren't reliable enough.". My answer to that is "When was the last time you saw an ATM that couldn't print a receipt? ATMs have to operate 24x365 with irregular maintenance and every random passer-by banging on them. Voting machines only have to operate for 12 hours at a time 4-5 times a year max, with somewhat-trained people right there to feed them paper and ribbons and other consumables and make sure nobody beats on them. If Diebold can make a reliable printer for an ATM, why can't they make one at least as reliable for a voting machine?".
Another check you can do is a fake election. You get representatives of several groups with an interest in the election, giving you N representatives. After the machines are set up, each rep can pick 1 machine from one polling place and have the election board pack it up and bring it back to a central place. Each rep then picks one machine (the only restriction is it can't be the one they selected from a polling place) and, with the others watching over their shoulder, enters a series of votes simulating say a dozen voters. The votes are tallied by the group and the exact votes that rep entered are agreed on. Once done, the votes from the machines are tallied as they would be for the real election and the tallies compared to the tallies the group agreed were actually entered. Any discrepancy indicates the machine aren't tallying votes accurately.
Note that, with the repeal of this law, minors still can't buy Mature or Adults-Only video games. Game stores are pretty good, on average, about honoring the ratings. The problem is, as noted, that in all the examples held up of minors getting "scarred" by violent games, it was their parents or another adult related to them that bought the game for them. What law against selling such games to minors, or against minors buying such games, is going to do a thing about that? The only law that'd help is one fining the adult who bought the game, and you're never ever going to hear a politician suggesting fining the parents for stupid decisions.
That wouldn't work very well, because in the US typically the shops aren't selling the game to the kid. Typically what happens is what's happened in the last 3-4 incidents to make the news: the parent or another adult buys the game, gives it to their kid, then gets outraged at the content of the game. The part where they bought it and handed it to little Johnny without checking it first seems to conveniently get forgotten. And how can the shop do anything about this? They only see the parent buying, and the parent's well over 18.
His network would be secure. Note that ability to connect to the AP is not the same as being able to connect to the network.
My network's that way. The AP is completely open and all encryption is disabled. However, the APs (I have two, one for 802.11a, one for 802.11b/g) connect (through a dedicated switch) to their own interface port on the central router. That interface does not have routing rules set up for it so the whole wireless network can only talk to itself and the router, not the rest of the LAN. The only way to get a routable connection is to connect to the router via an IPSEC VPN. Any wireless client can then set their own firewall to block any and all traffic except VPN traffic to/from the router. With this setup any bad guys who connect to my APs won't have the keys needed to connect via VPN, so all they can do is talk to other computers connected to my APs. Those will be firewalled and won't be listening to anything but the router, and any attempt to spoof the router's address will be seen by the router and trigger an alert (hasn't happened yet, I fear I've overestimated the kiddies' technical competence).
NB: I get the occasional bumbling attempt on the 11b/g AP, but so far nobody's even tried to connect to the 11a AP. I guess the kiddies cheaped out and got 11b/g-only wireless cards.
I think the author uses a confusing definition of high-level vs. low-level language. I've always thought of it as a matter of structure: a low-level language's constructs map relatively directly to hardware or machine-language constructs, a high-level language's constructs don't. The level of abstraction of the constructs doesn't matter, only the mapping between them and the hardware. So while vector operations may be a more abstract (higher level) concept than C's primitive arrays and loops to operate on them, a language implementing vectors and vector operations directly in the syntax would be a lower-level language (as far as vectors go) than C on hardware with a vector unit because it's vector construct maps directly to a hardware operation. His discussion seems to be that C and it's relatives don't map closely to hardware operations anymore, so they may not perform as well as languages that do map more closely. Well, duh. We knew that from the Lisp Machine where LISP was a low-level language and C wasn't.
The point about optimizations is more productive. The whole "interpreted languages are slower than compiled languages" deal came from a time when it wasn't feasible to compile at run-time. Bytecode blows that whole theory out of the water, but until Java bytecode wasn't thought about much (UCSD Pascal and Icon and possibly Forth are the only bytecode-based languages I know of that pre-date Java). You still can't compile Java on-the-fly feasibly, but you can compile Java bytecode in close enough to real-time to not make a difference. C++ programmers have been doing that for ages with inlined member functions, but that comes with all manner of headaches when classes change and inlined code elsewhere doesn't. Bytecode doesn't suffer from that. That's something a lot of programmers steeped in the advantages and limitations of C and C++ don't think about.
Nowhere in the decision does it say that. In fact, the judge spends some time on the fact that the shield does not apply when the journalists are themselves the targets of the legal action, as they would be if they were invading your privacy directly. In this case Apple was not targetting the bloggers themselves since, legally, Apple wouldn't have had a leg to stand on if they had (the bloggers never signed any NDAs with Apple, hence generally weren't obligated to protect Apple's secrets (the exception would've been hard for Apple to prove)). You've the same protections now that you had before this decision.
This isn't a good thing for Google. It turns the fraud situation on it's head. Having written software to try and do it, let me tell you it's hard to tie a sale back to an advertisement impression and/or click-through. Most of the ways involve either trusting the guy who'll be paying, depending on cookies to persist or maintaining a lot of server-side state to track an individual over the long term. The only case that's simple is where the viewer clicks on the ad and then performs the action in the same browsing session without ever leaving the site. Even if advertisers don't set out to defraud Google a lot of payments are going to drop through the cracks simply due to the normal things people do to avoid being tracked, or simply because the connection got lost because of the passage of time. If someone's setting out to defraud Google, it gets a lot worse really fast.
If I remember the text of the ruling correctly, the judge didn't completely refuse to visit the question. He said that he wasn't going to visit the question of whether they were journalists or not because he didn't have to. In this case they were acting as journalists, which was sufficient for the purposes of determining whether the shield law applied in this case regardless of whether or not they were journalists in a broader sense. This is actually a better ruling than merely saying bloggers are journalists. If taken as precedent it basically says that anyone is protected as a journalist when they're acting as a journalist, whether they're a full-time journalist or not.
Nope, you'd come right back to it. For half your orbit you'd be moving a bit faster than the station, for the other half you'd be moving a bit slower (due to difference in orbital radius), after one orbit the difference would be zero. To do what you describe you'd need a significant change in tangential velocity, and your push just can't produce enough delta V to make enough of a change in average orbital radius to be a problem. Keppler makes things behave counterintuitively in orbit.
D. Wait out one orbit and grab the station as you go by.
This is orbital physics we're dealing with. You're in a roughly circular orbit with a fairly high velocity already. That little push off isn't anywhere near enough to reach escape velocity, all it'll do is perturb your orbit slightly. Instead of orbiting with the station, you'll drift inwards a bit and then back outwards and you'll intersect the station's original orbit once every orbit (possibly twice, I'd have to work the math out all the way to be sure). Since the station's orbit's fairly short, I'm betting you'll meet up with it again before your air runs out.
One has to wonder how the site's story policy affects the drop-off. That is, is the drop-off because users are uninterested or not reading, or is it because after that time the story drops off the main pages and becomes hard to find to read?
In the Sunrise case here in the US that legitimized this practice of editing, the logic was that the consumer had already come to a financial agreement with the copyright holder when they purchased the video. The consumer would then have the right to edit the video any way they wanted, as long as they didn't make any additional copies not for personal use. The judge then ruled that if a consumer has a right to do something, they have a right to have someone else do that thing for them as long as no additional copies of the work exist outside the consumer's possession when it's all done.
Essentially, Sunrise wasn't selling a derivative work. They were selling the original, then selling the service of editing that original to the consumer's specs after purchase. The edited original went to the consumer, Sunrise retained no copies, and Sunrise had no edited copies in inventory except what they were working on for purchasers at the moment. The studios were angry, but there wasn't anything they could do.
Invoice showing the vendor sold that copy of Windows to you. Think of it this way: the COA is evidence that that copy of Windows is genuine, the invoice shows the link in the chain of custody that proves that you indeed paid for that copy and are the owner of it.
Note that that doesn't address whether the vendor owned the copy or was otherwise authorized to sell it to you. That's what the judge was hinting at in his ruling.
I've seen similar things. The judge is obliged to assume certain things, like the validity of the licensing scheme, unless one party or the other questions them. My bet is that the defendants here tried arguing within the assumptions of the EULA terms. In that case they'll lose. What they probably didn't do is argue that they never need to get to the EULA terms, they got a license from the actual purchase under the standard laws of commerce, that that license and contract of sale exist independently of the EULA and don't depend on acceptance of the EULA and that that's what the COA represents (since you get the COA without having to accept the terms of the EULA first). But since the defendants didn't argue that, the judge is constrained to work within what they did argue. You're right, he's hinting that if the defendants had argued differently he'd've come to a different conclusion.
My advice is a bit specific to the US, but here it is: don't make a First Amendment or copyright-law case out of a simple Uniform Commercial Code contract case.
True, but again the trick is to keep the rule iron-clad and simple. My rule catches your example, because it's not run from the Administration menu. My statement to the user who asked about it: "If it really worked, it'd've been available in the package management window that you use to install everything else and it'd've put itself in the Administration menu properly. It didn't, therefore it's trying to trick you.". It's all conditioned response. Windows conditions people to click OK no matter what. On most Unix systems (including OSX), it's feasible to tie administrative access and the Administration menu (or equivalent) together and condition users to automatically Cancel any request for the first that didn't come from an item on the second. Since I don't have to keep making exceptions, it quickly sinks in.
My feeling is the guys doing this for money aren't writing the malware. Using kits built by someone else yes, but it's a lot cheaper to use something already prepared than to invest heavily in your own tame uberhackers to come up with original software. The money guys are about ROI, and the ROI on original software just isn't there.
By tying into the system libraries, I mean tricks like the rootkits use (and that ancient DOS-based stealth viruses used) to make themselves invisible. Modify or override libc or the drivers that create the/proc filesystem so that to anyone else your processes and files simply don't exist or appear to be benign. See the Sony rootkit for an example. Sony's rootkit couldn't cloak itself as an ordinary user on a Unix-based system.
And no, malware isn't trying to hide from the human. It's trying to hide from the administrative user and the programs running as the administrative user. Like tripwire, or a program specifically designed to scan for and remove malware. It's the old DOS advice, "Check and clean your system after booting from a known-clean read-only boot floppy, never from your potentially-infected hard drive.", but you don't need to reboot to apply it (at least as long as you don't run random programs from outside sources as root). Whether this helps the user directly or not, it makes it a lot easier for other people to write automated tools that can bring a lot more expertise to bear on keeping a system cleaned up. It's not perfect, nothing ever will be, but it sets the bar a lot higher than it is on your typical Windows system.
Actually my approach is simple and requires a minimum of IQ points: "Everything you need to do that needs administrative access is on the "Administration" menu. Anything else is trying to trick you.". That's a nice, simple black-and-white rule that's easy for the average user to get their head around, much easier than the rules needed under Windows. This neatly gets them out of the habit of OK'ing every dialog they find because they don't run into that many extraneous dialogs that have to be dismissed. Those seem to be a Windows-specific artifact.
This even works for Web-based stuff. User: "But what if my browser prompts me to install something?"
Me: "Did you pick an item off the "Administration" menu?"
User: "No."
Me: "What did I just say about that, then?"
User: "It's trying to trick me."
Me: "And what do you do?"
User: "Click the "Cancel" button."
Me: "You're learning."
I swear, sometimes I think Windows is just plain neurotic the way it keeps asking for permission and confirmation all the time. Linux, *BSD and OSX aren't afraid to tell an application "No you can't do that.", why does Windows insist on making so sure an app really truly shouldn't do something dangerous?
Nope. On modern GUIs you only get prompted for the admin password when you directly try to perform an administrative task. If I click on the printer management item in the administration menu, I expect to be asked for the root password. On the other hand, if I try to run a game I do not expect to be asked for the root password and I'm going to be alarmed if that dialog pops up. Thus my advice to people running various Linux distros or OSX with this facility: if you don't know that what you just tried to do requires admin privileges, the correct button is the one labelled "Cancel". The times this advice is wrong are rare indeed.
My thought is that there's three reasons Macs and *nixen have fewer viruses.
It's partly the lack of market share. That's offset to a large degree by the extra l33t points accruing to the guy who manages to release the first malware to get widespread penetration into those "invulnerable" systems.
It's partly user sophistication. Except that Macs are targeted at people who're even less sophisticated than Windows users, who don't want to deal with things like the problems added new hardware to a Windows system. You might be able to argue that a Linux or FreeBSD user's more likely to be a geek, but not a Mac user.
It's in large part inherent system design. The basic design point: the seperation between ordinary users and the administrative user (root). That seperation means that, even if you do get infected with malware, the malware can't spread into the system itself. It can't tie into system libraries, it can't have itself started at system startup, it can't disable system services (like the firewall or the malware scanner) and it can't hide itself from the administrative user. This provides a two-layer defense similar to the layout of a medieval castle: once the attackers break through the outer wall, they have to start all over again breaking through the defenses of the inner keep (while being stuck in the yard between the keep and the wall, easy prey for the defenders in the keep). Changes in market share and declining user sophistication won't have any effect on this aspect of things.
Oh, exactly. There's a big difference between what the BSA claims, and what a court would hold if they ever got to rule on it. But first you have to get to where a court rules on it. The BSA's going to make that as expensive as possible, including probably tactics like filing the court paperwork (citing your own refusal to allow them to audit you, using their interpretation of everything) to get your equipment confiscated pending the outcome of legal action. In short, they're going to try every trick they can to make it a choice between complying with their demands (whether legal or not) or being driven out of business. Not many companies can afford to stick it out long enough to win, which is what the BSA counts on.
The concerns the article expresses are valid but a bit overblown. Yes, distros have to offer source code. Yes, that means for all packages even if you only modify a few. The FSF has a point, that's the only way to insure the source for your distro is available if the upstream moves to newer versions that aren't compatible with your stuff. But there's several ways to handle this without much trouble:
Offer source directly with the binaries. Including the source on CDs/DVDs along with binaries merely requires more discs (which you should charge for if you offer physical media). Including source packages on the server alongside the binary packages, by the FSF's own statements, satisfies your obligation under the GPL. If people don't download the source at the time, you've still satisfied your obligation to make it available. Yes it'll cost some server space and bandwidth, but your binaries are already using a bunch of that and you've handled it.
Distribute only your modified packages and provide source for them. Direct people to the appropriate distribution's site for the unmodified packages. Or host ISOs of the base distribution in unmodified form (assuming you qualify for the "non-commercial" label and can take advantage of the pass-along option).
Frankly, were I doing a Linux distribution, I'd opt for the first course. It's got the fewest issues down the road, and it follows the lead of the major distros so I'm unlikely to run into unexpected trouble.
Read the software license you agreed to when you installed most any software. Almost all of them have a clause in there that says you agree, at your expense, to let the software maker or their appointed agent come in at any time and audit you for license compliance. Note that you get to foot the bill even if they find you're 100% in compliance. If you don't agree to the audit, you're automatically in violation of your license agreement.
And you won't be in compliance, that's a guarantee. Remember that, by the BSA's rules, merely having all the original media, license certificates and product keys for every single copy you've got installed is not sufficient. Only an original receipt or invoice made out to your company proves legal ownership, and your company probably threw those away long ago.
Slashdot Mirror
It's not only possible, it's easy. The main thing to watch is libraries. All you have to do is avoid using libraries available only under the GPL in your program. The only critical libraries that your program will have to use are glibc and the GCC C++ library module, and both of those are under LGPL-style licenses. As long as you dynamically link to them (so the library object code isn't physically included in your executable) you don't have a licensing problem. Other libraries you'll have to look at their license terms to see whether they're compatible and how you have to use them to be compatible, but none of those are required to run on Linux and you can just not use them if you can't find a way to be compatible with their licenses. GTK (Gnome) and Qt (KDE) are probably highly desirable for GUI apps, but GTK's under the LGPL and Qt has a commercial license available so you can use both without having to open-source your code.
I'm not sure why companies would need any special outline for Linux. That it's open-source is irrelevant for most software, really. If you're making a kernel module the issue comes into play, but very few things other than actual hardware devices need kernel modules. If you include GPL'd libraries in your software there's a licensing issue, but then if you include any libraries licensed from third parties you've got a licensing issue when you start distributing them and you're going to have to do some negotiating and cough up some money. I don't think there's any GPL'd libraries that apps on Linux have to use, so any app should be able to avoid the issue if they want to. The only thing left is integration into the system:
- Installation of the software. Not much to say here. A simple tar file that can be unpacked and copied under
/usr/local, or that's got an installation script that does the work, should work on any Unix out there including Linux. At worst you've got to add a library directory to /etc/ld.so.conf, but usually a small wrapper script that sets LD_LIBRARY_PATH appropriately obviates the need for that. If you want to use the native packaging system you've got to build binary packages, but that's usually straightforward and covered in the documentation for each distro.
- Integration into the system startup scripts. There's a couple of different layouts for the startup script directories, and each distro has it's own little customizations you have to accomodate for perfect integration (things like how the script should check for the software already being started during runlevel changes, stuff like that). But how much software really needs to be set running during startup? Most doesn't, but the few packages that do have some complexity on their hands.
- Desktop integration. This isn't a Linux issue, it's a Gnome and KDE issue (those being the two major ones these days). Their Web sites have guides on how to do this right IIRC, and if you follow them it should work for that desktop on any platform the desktop runs on. Linux is simply another platform.
- Integration with the desktop. Um, this is Unix. There is no single desktop. Any user on the system can run any desktop, and in fact run different desktops at different times. Best bet is to follow the guides for integration, check for each desktop and integrate with all that're installed, and provide a single executable (or a wrapper script) that a user can run from the command line that'll start your app. That last insures users can use your app without any desktop integration at all by simply manually creating a launcher for it where they want one.
- Copy protection. This can be an issue. The world outside Windows is remarkably hostile to the sorts of copy-protection schemes seen in Windows software, and Linux isn't unique in this. License key servers can be used, but they tend to cause more headaches for your customers (even when working properly) than for pirates. Hardware keying is a pain since Unixes tend to hide the hardware so well the detailed information isn't readily available (you can get it, but it takes a fair amount of hackery).
Have I missed anything? I don't think I have, and aside from the issue of copy protection none of the above needs any special communication or coordination between the software vendor and the Linux community or distributions to deal with beyond reading the relevant docs. Maybe it's that the vendors have a problem believing it can be that simple after all these years of dealing with the complexities of Windows?There really isn't any. The only one Diebold &co have come up with is "The printers aren't reliable enough.". My answer to that is "When was the last time you saw an ATM that couldn't print a receipt? ATMs have to operate 24x365 with irregular maintenance and every random passer-by banging on them. Voting machines only have to operate for 12 hours at a time 4-5 times a year max, with somewhat-trained people right there to feed them paper and ribbons and other consumables and make sure nobody beats on them. If Diebold can make a reliable printer for an ATM, why can't they make one at least as reliable for a voting machine?".
Another check you can do is a fake election. You get representatives of several groups with an interest in the election, giving you N representatives. After the machines are set up, each rep can pick 1 machine from one polling place and have the election board pack it up and bring it back to a central place. Each rep then picks one machine (the only restriction is it can't be the one they selected from a polling place) and, with the others watching over their shoulder, enters a series of votes simulating say a dozen voters. The votes are tallied by the group and the exact votes that rep entered are agreed on. Once done, the votes from the machines are tallied as they would be for the real election and the tallies compared to the tallies the group agreed were actually entered. Any discrepancy indicates the machine aren't tallying votes accurately.
Note that, with the repeal of this law, minors still can't buy Mature or Adults-Only video games. Game stores are pretty good, on average, about honoring the ratings. The problem is, as noted, that in all the examples held up of minors getting "scarred" by violent games, it was their parents or another adult related to them that bought the game for them. What law against selling such games to minors, or against minors buying such games, is going to do a thing about that? The only law that'd help is one fining the adult who bought the game, and you're never ever going to hear a politician suggesting fining the parents for stupid decisions.
That wouldn't work very well, because in the US typically the shops aren't selling the game to the kid. Typically what happens is what's happened in the last 3-4 incidents to make the news: the parent or another adult buys the game, gives it to their kid, then gets outraged at the content of the game. The part where they bought it and handed it to little Johnny without checking it first seems to conveniently get forgotten. And how can the shop do anything about this? They only see the parent buying, and the parent's well over 18.
His network would be secure. Note that ability to connect to the AP is not the same as being able to connect to the network.
My network's that way. The AP is completely open and all encryption is disabled. However, the APs (I have two, one for 802.11a, one for 802.11b/g) connect (through a dedicated switch) to their own interface port on the central router. That interface does not have routing rules set up for it so the whole wireless network can only talk to itself and the router, not the rest of the LAN. The only way to get a routable connection is to connect to the router via an IPSEC VPN. Any wireless client can then set their own firewall to block any and all traffic except VPN traffic to/from the router. With this setup any bad guys who connect to my APs won't have the keys needed to connect via VPN, so all they can do is talk to other computers connected to my APs. Those will be firewalled and won't be listening to anything but the router, and any attempt to spoof the router's address will be seen by the router and trigger an alert (hasn't happened yet, I fear I've overestimated the kiddies' technical competence).
NB: I get the occasional bumbling attempt on the 11b/g AP, but so far nobody's even tried to connect to the 11a AP. I guess the kiddies cheaped out and got 11b/g-only wireless cards.
I think the author uses a confusing definition of high-level vs. low-level language. I've always thought of it as a matter of structure: a low-level language's constructs map relatively directly to hardware or machine-language constructs, a high-level language's constructs don't. The level of abstraction of the constructs doesn't matter, only the mapping between them and the hardware. So while vector operations may be a more abstract (higher level) concept than C's primitive arrays and loops to operate on them, a language implementing vectors and vector operations directly in the syntax would be a lower-level language (as far as vectors go) than C on hardware with a vector unit because it's vector construct maps directly to a hardware operation. His discussion seems to be that C and it's relatives don't map closely to hardware operations anymore, so they may not perform as well as languages that do map more closely. Well, duh. We knew that from the Lisp Machine where LISP was a low-level language and C wasn't.
The point about optimizations is more productive. The whole "interpreted languages are slower than compiled languages" deal came from a time when it wasn't feasible to compile at run-time. Bytecode blows that whole theory out of the water, but until Java bytecode wasn't thought about much (UCSD Pascal and Icon and possibly Forth are the only bytecode-based languages I know of that pre-date Java). You still can't compile Java on-the-fly feasibly, but you can compile Java bytecode in close enough to real-time to not make a difference. C++ programmers have been doing that for ages with inlined member functions, but that comes with all manner of headaches when classes change and inlined code elsewhere doesn't. Bytecode doesn't suffer from that. That's something a lot of programmers steeped in the advantages and limitations of C and C++ don't think about.
Nowhere in the decision does it say that. In fact, the judge spends some time on the fact that the shield does not apply when the journalists are themselves the targets of the legal action, as they would be if they were invading your privacy directly. In this case Apple was not targetting the bloggers themselves since, legally, Apple wouldn't have had a leg to stand on if they had (the bloggers never signed any NDAs with Apple, hence generally weren't obligated to protect Apple's secrets (the exception would've been hard for Apple to prove)). You've the same protections now that you had before this decision.
This isn't a good thing for Google. It turns the fraud situation on it's head. Having written software to try and do it, let me tell you it's hard to tie a sale back to an advertisement impression and/or click-through. Most of the ways involve either trusting the guy who'll be paying, depending on cookies to persist or maintaining a lot of server-side state to track an individual over the long term. The only case that's simple is where the viewer clicks on the ad and then performs the action in the same browsing session without ever leaving the site. Even if advertisers don't set out to defraud Google a lot of payments are going to drop through the cracks simply due to the normal things people do to avoid being tracked, or simply because the connection got lost because of the passage of time. If someone's setting out to defraud Google, it gets a lot worse really fast.
If I remember the text of the ruling correctly, the judge didn't completely refuse to visit the question. He said that he wasn't going to visit the question of whether they were journalists or not because he didn't have to. In this case they were acting as journalists, which was sufficient for the purposes of determining whether the shield law applied in this case regardless of whether or not they were journalists in a broader sense. This is actually a better ruling than merely saying bloggers are journalists. If taken as precedent it basically says that anyone is protected as a journalist when they're acting as a journalist, whether they're a full-time journalist or not.
Perhaps you should investigate the uses of the user.js file instead of editing prefs.js directly?
Nope, you'd come right back to it. For half your orbit you'd be moving a bit faster than the station, for the other half you'd be moving a bit slower (due to difference in orbital radius), after one orbit the difference would be zero. To do what you describe you'd need a significant change in tangential velocity, and your push just can't produce enough delta V to make enough of a change in average orbital radius to be a problem. Keppler makes things behave counterintuitively in orbit.
D. Wait out one orbit and grab the station as you go by.
This is orbital physics we're dealing with. You're in a roughly circular orbit with a fairly high velocity already. That little push off isn't anywhere near enough to reach escape velocity, all it'll do is perturb your orbit slightly. Instead of orbiting with the station, you'll drift inwards a bit and then back outwards and you'll intersect the station's original orbit once every orbit (possibly twice, I'd have to work the math out all the way to be sure). Since the station's orbit's fairly short, I'm betting you'll meet up with it again before your air runs out.
One has to wonder how the site's story policy affects the drop-off. That is, is the drop-off because users are uninterested or not reading, or is it because after that time the story drops off the main pages and becomes hard to find to read?
In the Sunrise case here in the US that legitimized this practice of editing, the logic was that the consumer had already come to a financial agreement with the copyright holder when they purchased the video. The consumer would then have the right to edit the video any way they wanted, as long as they didn't make any additional copies not for personal use. The judge then ruled that if a consumer has a right to do something, they have a right to have someone else do that thing for them as long as no additional copies of the work exist outside the consumer's possession when it's all done.
Essentially, Sunrise wasn't selling a derivative work. They were selling the original, then selling the service of editing that original to the consumer's specs after purchase. The edited original went to the consumer, Sunrise retained no copies, and Sunrise had no edited copies in inventory except what they were working on for purchasers at the moment. The studios were angry, but there wasn't anything they could do.
Invoice showing the vendor sold that copy of Windows to you. Think of it this way: the COA is evidence that that copy of Windows is genuine, the invoice shows the link in the chain of custody that proves that you indeed paid for that copy and are the owner of it.
Note that that doesn't address whether the vendor owned the copy or was otherwise authorized to sell it to you. That's what the judge was hinting at in his ruling.
I've seen similar things. The judge is obliged to assume certain things, like the validity of the licensing scheme, unless one party or the other questions them. My bet is that the defendants here tried arguing within the assumptions of the EULA terms. In that case they'll lose. What they probably didn't do is argue that they never need to get to the EULA terms, they got a license from the actual purchase under the standard laws of commerce, that that license and contract of sale exist independently of the EULA and don't depend on acceptance of the EULA and that that's what the COA represents (since you get the COA without having to accept the terms of the EULA first). But since the defendants didn't argue that, the judge is constrained to work within what they did argue. You're right, he's hinting that if the defendants had argued differently he'd've come to a different conclusion.
My advice is a bit specific to the US, but here it is: don't make a First Amendment or copyright-law case out of a simple Uniform Commercial Code contract case.
True, but again the trick is to keep the rule iron-clad and simple. My rule catches your example, because it's not run from the Administration menu. My statement to the user who asked about it: "If it really worked, it'd've been available in the package management window that you use to install everything else and it'd've put itself in the Administration menu properly. It didn't, therefore it's trying to trick you.". It's all conditioned response. Windows conditions people to click OK no matter what. On most Unix systems (including OSX), it's feasible to tie administrative access and the Administration menu (or equivalent) together and condition users to automatically Cancel any request for the first that didn't come from an item on the second. Since I don't have to keep making exceptions, it quickly sinks in.
My feeling is the guys doing this for money aren't writing the malware. Using kits built by someone else yes, but it's a lot cheaper to use something already prepared than to invest heavily in your own tame uberhackers to come up with original software. The money guys are about ROI, and the ROI on original software just isn't there.
By tying into the system libraries, I mean tricks like the rootkits use (and that ancient DOS-based stealth viruses used) to make themselves invisible. Modify or override libc or the drivers that create the /proc filesystem so that to anyone else your processes and files simply don't exist or appear to be benign. See the Sony rootkit for an example. Sony's rootkit couldn't cloak itself as an ordinary user on a Unix-based system.
And no, malware isn't trying to hide from the human. It's trying to hide from the administrative user and the programs running as the administrative user. Like tripwire, or a program specifically designed to scan for and remove malware. It's the old DOS advice, "Check and clean your system after booting from a known-clean read-only boot floppy, never from your potentially-infected hard drive.", but you don't need to reboot to apply it (at least as long as you don't run random programs from outside sources as root). Whether this helps the user directly or not, it makes it a lot easier for other people to write automated tools that can bring a lot more expertise to bear on keeping a system cleaned up. It's not perfect, nothing ever will be, but it sets the bar a lot higher than it is on your typical Windows system.
Actually my approach is simple and requires a minimum of IQ points: "Everything you need to do that needs administrative access is on the "Administration" menu. Anything else is trying to trick you.". That's a nice, simple black-and-white rule that's easy for the average user to get their head around, much easier than the rules needed under Windows. This neatly gets them out of the habit of OK'ing every dialog they find because they don't run into that many extraneous dialogs that have to be dismissed. Those seem to be a Windows-specific artifact.
This even works for Web-based stuff.
User: "But what if my browser prompts me to install something?"
Me: "Did you pick an item off the "Administration" menu?"
User: "No."
Me: "What did I just say about that, then?"
User: "It's trying to trick me."
Me: "And what do you do?"
User: "Click the "Cancel" button."
Me: "You're learning."
I swear, sometimes I think Windows is just plain neurotic the way it keeps asking for permission and confirmation all the time. Linux, *BSD and OSX aren't afraid to tell an application "No you can't do that.", why does Windows insist on making so sure an app really truly shouldn't do something dangerous?
Nope. On modern GUIs you only get prompted for the admin password when you directly try to perform an administrative task. If I click on the printer management item in the administration menu, I expect to be asked for the root password. On the other hand, if I try to run a game I do not expect to be asked for the root password and I'm going to be alarmed if that dialog pops up. Thus my advice to people running various Linux distros or OSX with this facility: if you don't know that what you just tried to do requires admin privileges, the correct button is the one labelled "Cancel". The times this advice is wrong are rare indeed.
My thought is that there's three reasons Macs and *nixen have fewer viruses.
Oh, exactly. There's a big difference between what the BSA claims, and what a court would hold if they ever got to rule on it. But first you have to get to where a court rules on it. The BSA's going to make that as expensive as possible, including probably tactics like filing the court paperwork (citing your own refusal to allow them to audit you, using their interpretation of everything) to get your equipment confiscated pending the outcome of legal action. In short, they're going to try every trick they can to make it a choice between complying with their demands (whether legal or not) or being driven out of business. Not many companies can afford to stick it out long enough to win, which is what the BSA counts on.
The concerns the article expresses are valid but a bit overblown. Yes, distros have to offer source code. Yes, that means for all packages even if you only modify a few. The FSF has a point, that's the only way to insure the source for your distro is available if the upstream moves to newer versions that aren't compatible with your stuff. But there's several ways to handle this without much trouble:
- Offer source directly with the binaries. Including the source on CDs/DVDs along with binaries merely requires more discs (which you should charge for if you offer physical media). Including source packages on the server alongside the binary packages, by the FSF's own statements, satisfies your obligation under the GPL. If people don't download the source at the time, you've still satisfied your obligation to make it available. Yes it'll cost some server space and bandwidth, but your binaries are already using a bunch of that and you've handled it.
- Distribute only your modified packages and provide source for them. Direct people to the appropriate distribution's site for the unmodified packages. Or host ISOs of the base distribution in unmodified form (assuming you qualify for the "non-commercial" label and can take advantage of the pass-along option).
Frankly, were I doing a Linux distribution, I'd opt for the first course. It's got the fewest issues down the road, and it follows the lead of the major distros so I'm unlikely to run into unexpected trouble.Read the software license you agreed to when you installed most any software. Almost all of them have a clause in there that says you agree, at your expense, to let the software maker or their appointed agent come in at any time and audit you for license compliance. Note that you get to foot the bill even if they find you're 100% in compliance. If you don't agree to the audit, you're automatically in violation of your license agreement.
And you won't be in compliance, that's a guarantee. Remember that, by the BSA's rules, merely having all the original media, license certificates and product keys for every single copy you've got installed is not sufficient. Only an original receipt or invoice made out to your company proves legal ownership, and your company probably threw those away long ago.