This isn't a net neutrality issue per se (although not everyone agrees on the same definition of net neutrality). Customers should be allowed to buy faster or slower network connections.
The problem that net neutrality tries to address is where ISPs charge *providers* for fast access from customers. It's sort of like an extortion racket -- sorry, we're going to make your website's user experience crappy unless you pay up.
The reason why we want to apply this to the Internet in particular is because it's an essential service with not many ways to get access -- mostly controlled by monopolies.
Driving analogy:
Buying faster access, e.g. letting drivers bypass traffic by using toll roads is OK. The customer is paying for a better driving experience.
Charging providers is like there's a Costco next to a highway, but the highway administrator won't let people drive into Costco from the road just off the highway exit -- they have to take a detour instead unless Costco pays them a bunch of money to open a gate. However, Sam's Club does pay up so their highway entrance is open for speedy access.
The even sillier thing is that on the net, the highway is more or less open to everyone at low cost, and Costco paid money to make sure they're next to a highway. But as soon as you leave your house, someone looks at where you're going and speeds you up or slows you down depending on where you're going.
So while it's true that businesses sometimes make agreements with other businesses that ultimately screw over both the competition and their customers, it's a lot worse when you can't even avoid using their services without living in a cave.
The kernel can only defragment pages, which are 4KB on most Linux systems. If you have a page with 4080 bytes of leaked memory and 16 bytes of memory that you actually use, accessing that memory will swap in the entire page.
You can't move stuff around within a page because the address would change (moving pages is OK because all memory accesses go through the TLB), unless you have a way of fixing up all the pointers to point at the new location. That's generally only possible in a type-safe language like Java, so the memory manager can guarantee that it's modifying a pointer and not some arbitrary data. The Java virtual machine can move objects around as part of the garbage collection process, defragmenting the heap in the process.
Clustering by allocation site might work for some applications, but if you allocate, say, a string, it's difficult to tell if the string is going to be freed now, or later, or never, much less whether it'll be freed at the same time as any other objects. It might depend on the input data.
I'd be nice if I could allow people to use my wifi network, but ONLY to VPN to their own network. That way, they could use it to get connectivity but can't do stupid stuff using my IP address (for the same reason that some sites block Tor exit nodes).
The other problem is that like with all DRM systems, you're in trouble if Valve becomes insolvent or decides to turn evil and shut downs their servers. For now though things seems OK considering:
Valve makes a lot of money. They're not likely to go under anytime soon.
Valve has made at least some vague promises to unlock the DRM (maybe only on their games, but better than nothing) if they're unable to continue running Steam.
As a privately owned company, they're somewhat less likely to try to screw over their customers for short-term gain. They also seem a lot less corporate than most major game publishers.
First, it had a relatively large 10" screen and a nice, non-cramped keyboard. Having a screen that large raised the price point to $500-$600. IMHO, the thing that made netbooks popular was the low starting price point (EEE was promised for $200, I think it ended up at $300 on launch). It turns out people don't mind a tiny 7" screen if it means saving a couple hundred bucks. Now that the netbook market has been established, 10" screen netbooks are affordable and $500 might-as-well-call-it-a-laptop netbooks are selling OK, but I think it probably took them a while to get those economies of scale and enough market demand.
Secondly, it used an underpowered 416mhz XScale processor -- the kind used in pre-smartphone PDAs circa 2003, but the Foleo was announced in 2007. This pretty much hobbled the ability to use it as a desktop, because it wasn't fast enough to run a full Linux desktop stack or do stuff like play video. Instead, they had their own custom user interface and you couldn't run standard apps out of the box. This probably lead to it being marketed as a "mobile companion" rather than a computer. They should have done like EEE and thrown a 800 mhz Celeron processor in there, but it probably would have messed up the design (needing to add fans for cooling) and they'd also have to shrink the screen to balance costs. It's only now in 2009-2010 that you can get 1-2ghz ARM processors which are low-power, low-heat, cheap, and powerful enough to run desktop-class apps.
In summary, the Foleo fells somewhere along the big gap betweens laptops and PDAs, but the technology wasn't powerful enough or cheap enough to carve out an entirely new niche there. Netbooks succeeded because they were basically just cheap laptops. Now the iPad looks like it's going to fill that gap (although you still can't carry it in your pocket). It's got enough apps that people don't care that it's not a full desktop OS. It can play 10 hours of video. And it's a cheap tablet -- of course, Apple's selling it for a nice premium, but it's still cheaper than the overpriced, ultimately unsuccessful Windows-based tablets even if the hardware isn't as capable.
There are some retail games (not made by Valve) -- as in you buy it in a box from a brick-and-mortar store and install the game off a DVD -- which require Steam in order to play the game.
I believe Steam lets you play offline for some period of time after authenticating, so this places it somewhere between the "1-time online activation on installation" style DRM and the Ubisoft "must be connected at absolutely all times" DRM.
I get many of my games on Steam, but I don't want to see them become the *only* option.
Right now, all the games that support both Mac and Windows are marked as "SteamPlay" meaning you only have to buy one copy of the game to play it on all platforms. I don't know if that's guaranteed if we'll start seeing exceptions in the future.
Freedom of speech doesn't protect you from getting sued for copyright infringement, especially since it's a private party (not the government) that's suing.
Someone could write an aimbot that simulates a human-level of inaccuracy. The server would have a hard time telling the difference between a bot and a player with a really good aim, and you don't want to accidentally ban a legitimate player.
Sanitization has been on by default since WebOS 1.1.
It's up to the individual developers to make sure their app is secure -- which it is by default if they don't disable the security features provided by WebOS.
It's not really that new of a market. Windows Mobile and PalmOS allowed you to install any apps you want.
The only real difference is that the iPhone has a central app store. I think it makes sense for Apple to have rules about what they sell on the App Store. The problem is that you can *only* get apps from the App Store, you can't install apps from anywhere else.
I don't buy the argument that people really want a locked down platform. They might be willing to put up with it, since it's the only way you can play (true for both consoles and now the iPhone), but it's mostly only Apple who's benefiting, not us.
People who really want a walled garden can just stick to installing stuff from the app store and not do any sideloading. Android I believe has a toggle switch to allow installing non-market apps.
There's really nothing wrong with copying ideas, and furthermore ideas can't be copyrighted. (And don't tell me that you're in favor of patenting this kind of stuff.) Otherwise, we wouldn't have the computer industry or really any other industry.
I do think credit should be given where credit is due, though.
Great: We know you love Product X so much, so we hired the developer / bought the company and we're including it in our OS.
Good: We saw this awesome feature by Developer X, and now we're incorporating into our OS.
OK: We're introducing this great feature as a core feature of our OS.
Bad: We just invented this totally radical new feature. See what happens when innovative minds get to innovating new innovations.
Just to nitpick your example, the object doesn't get garbage collected immediately in Java. Once it's no longer referenced, it just becomes eligible for collection, and the garbage collection happens later when the virtual machine needs to clear up some heap space.
That's particularly important if your object is holding on to external resources, like forgetting to close file i/o streams before unreferencing the object. If the garbage collector isn't smart enough, you could run out of file descriptors before it runs a garbage collection.
On the other hand, some reference-counted languages do free objects at the exact moment that you set the variable to null. And smart pointers in C++ may free the object as soon as it goes out of scope, as in your example. As opposed to Java, where it's difficult to predict when exactly the memory is going to get freed.
Finally, the idea of setting a variable to null has some merit in certain circumstances (although it's not necessary most of the time, as you pointed out). If you have code like this:
Just the fact that they're discriminating based on version is already pretty bad. They ought to just send you a SMS with a warning message every week or something.
Any LGPL-licensed code can be converted into GPL per section 3 of the LGPL v2.1, so the effect should be the same as dual-licensing LGPL/GPL. In practice, this means the work as a whole must be used as GPL, but you could potentially take another part of the code that doesn't rely on the GPL library and reuse that in a LGPL'd project.
I think part of the appeal of the iPhone to developers (not me, I don't like the iPhone personally) besides the large market, is that when you develop an app, it looks exactly the same on every iPhone. You don't have to worry about screen size or hardware capabilities. There's some divergence now since the iPhone 3GS is considerably faster than the older iPhones, but it's not nearly as big a difference as other phones.
Android has a similar problem to the old JavaME model. You have to design for the lowest common denominator. It's a little better, because JavaME had a really low common denominator (dumb phones with limited memory and CPU) while Android is aimed at smartphones with a touchscreen interface.
I think it's because retail products take up physical space, so there's an incentive to clear inventory. With digital distribution, they can sell as many or as few copies as they want in order to maximize revenue.
I can imagine that for some companies, they don't want to mention the percent to avoid revealing their actual sales figures -- since the total amount of money donated will probably show up in the charity's public disclosures. Also, it lets them change it according to how generous they're feeling at the moment and their financial situation.
It would be nice if they at least announced the total amount raised, which gives you a reasonable sense of whether it's a significant amount of money for a company of their size, or if the entirety of the donation turned out to be a check for $1000 for a nation-wide promotion.
I'd guess that beyond just being computationally difficult, it'd look kind of weird just because of the latency and the fact that character movements are not perfectly smooth/natural.
The most annoying thing about bots in versus is that they pretty much refuse to help get a special infected off you until you've already lost most of your internal organs. They stand right next to you and watch you squirm for about 5-15 seconds.
That's got to be more than just stupidity. I think there's just some variable somewhere to make them completely ineffective at saving people.
This isn't a net neutrality issue per se (although not everyone agrees on the same definition of net neutrality). Customers should be allowed to buy faster or slower network connections.
The problem that net neutrality tries to address is where ISPs charge *providers* for fast access from customers. It's sort of like an extortion racket -- sorry, we're going to make your website's user experience crappy unless you pay up.
The reason why we want to apply this to the Internet in particular is because it's an essential service with not many ways to get access -- mostly controlled by monopolies.
Driving analogy:
So while it's true that businesses sometimes make agreements with other businesses that ultimately screw over both the competition and their customers, it's a lot worse when you can't even avoid using their services without living in a cave.
The kernel can only defragment pages, which are 4KB on most Linux systems. If you have a page with 4080 bytes of leaked memory and 16 bytes of memory that you actually use, accessing that memory will swap in the entire page.
You can't move stuff around within a page because the address would change (moving pages is OK because all memory accesses go through the TLB), unless you have a way of fixing up all the pointers to point at the new location. That's generally only possible in a type-safe language like Java, so the memory manager can guarantee that it's modifying a pointer and not some arbitrary data. The Java virtual machine can move objects around as part of the garbage collection process, defragmenting the heap in the process.
Clustering by allocation site might work for some applications, but if you allocate, say, a string, it's difficult to tell if the string is going to be freed now, or later, or never, much less whether it'll be freed at the same time as any other objects. It might depend on the input data.
I'd be nice if I could allow people to use my wifi network, but ONLY to VPN to their own network. That way, they could use it to get connectivity but can't do stupid stuff using my IP address (for the same reason that some sites block Tor exit nodes).
The other problem is that like with all DRM systems, you're in trouble if Valve becomes insolvent or decides to turn evil and shut downs their servers. For now though things seems OK considering:
There were a couple fundamental problems:
First, it had a relatively large 10" screen and a nice, non-cramped keyboard. Having a screen that large raised the price point to $500-$600. IMHO, the thing that made netbooks popular was the low starting price point (EEE was promised for $200, I think it ended up at $300 on launch). It turns out people don't mind a tiny 7" screen if it means saving a couple hundred bucks. Now that the netbook market has been established, 10" screen netbooks are affordable and $500 might-as-well-call-it-a-laptop netbooks are selling OK, but I think it probably took them a while to get those economies of scale and enough market demand.
Secondly, it used an underpowered 416mhz XScale processor -- the kind used in pre-smartphone PDAs circa 2003, but the Foleo was announced in 2007. This pretty much hobbled the ability to use it as a desktop, because it wasn't fast enough to run a full Linux desktop stack or do stuff like play video. Instead, they had their own custom user interface and you couldn't run standard apps out of the box. This probably lead to it being marketed as a "mobile companion" rather than a computer. They should have done like EEE and thrown a 800 mhz Celeron processor in there, but it probably would have messed up the design (needing to add fans for cooling) and they'd also have to shrink the screen to balance costs. It's only now in 2009-2010 that you can get 1-2ghz ARM processors which are low-power, low-heat, cheap, and powerful enough to run desktop-class apps.
In summary, the Foleo fells somewhere along the big gap betweens laptops and PDAs, but the technology wasn't powerful enough or cheap enough to carve out an entirely new niche there. Netbooks succeeded because they were basically just cheap laptops. Now the iPad looks like it's going to fill that gap (although you still can't carry it in your pocket). It's got enough apps that people don't care that it's not a full desktop OS. It can play 10 hours of video. And it's a cheap tablet -- of course, Apple's selling it for a nice premium, but it's still cheaper than the overpriced, ultimately unsuccessful Windows-based tablets even if the hardware isn't as capable.
There are some retail games (not made by Valve) -- as in you buy it in a box from a brick-and-mortar store and install the game off a DVD -- which require Steam in order to play the game.
I believe Steam lets you play offline for some period of time after authenticating, so this places it somewhere between the "1-time online activation on installation" style DRM and the Ubisoft "must be connected at absolutely all times" DRM.
I get many of my games on Steam, but I don't want to see them become the *only* option.
From the article:
Right now, all the games that support both Mac and Windows are marked as "SteamPlay" meaning you only have to buy one copy of the game to play it on all platforms. I don't know if that's guaranteed if we'll start seeing exceptions in the future.
Freedom of speech doesn't protect you from getting sued for copyright infringement, especially since it's a private party (not the government) that's suing.
Someone could write an aimbot that simulates a human-level of inaccuracy. The server would have a hard time telling the difference between a bot and a player with a really good aim, and you don't want to accidentally ban a legitimate player.
Sanitization has been on by default since WebOS 1.1.
It's up to the individual developers to make sure their app is secure -- which it is by default if they don't disable the security features provided by WebOS.
You have to explicitly enable the "I know what I'm doing, stop protecting me" flag in your app to allow these types of exploits.
http://developer.palm.com/index.php?option=com_content&view=article&id=1756
It's not really that new of a market. Windows Mobile and PalmOS allowed you to install any apps you want.
The only real difference is that the iPhone has a central app store. I think it makes sense for Apple to have rules about what they sell on the App Store. The problem is that you can *only* get apps from the App Store, you can't install apps from anywhere else.
I don't buy the argument that people really want a locked down platform. They might be willing to put up with it, since it's the only way you can play (true for both consoles and now the iPhone), but it's mostly only Apple who's benefiting, not us.
People who really want a walled garden can just stick to installing stuff from the app store and not do any sideloading. Android I believe has a toggle switch to allow installing non-market apps.
For example from 2000:
http://the-gadgeteer.com/2000/12/10/gamepad_for_palm_iii_and_vii_series_pdas_review/
And
http://the-gadgeteer.com/2002/01/31/snapnplay_visor_game_pad_review/
You can probably find earlier examples.
There's really nothing wrong with copying ideas, and furthermore ideas can't be copyrighted. (And don't tell me that you're in favor of patenting this kind of stuff.) Otherwise, we wouldn't have the computer industry or really any other industry.
I do think credit should be given where credit is due, though.
Great: We know you love Product X so much, so we hired the developer / bought the company and we're including it in our OS.
Because many government pension plans are heavily invested in the stock market. See for example CalPERS.
Just to nitpick your example, the object doesn't get garbage collected immediately in Java. Once it's no longer referenced, it just becomes eligible for collection, and the garbage collection happens later when the virtual machine needs to clear up some heap space.
That's particularly important if your object is holding on to external resources, like forgetting to close file i/o streams before unreferencing the object. If the garbage collector isn't smart enough, you could run out of file descriptors before it runs a garbage collection.
On the other hand, some reference-counted languages do free objects at the exact moment that you set the variable to null. And smart pointers in C++ may free the object as soon as it goes out of scope, as in your example. As opposed to Java, where it's difficult to predict when exactly the memory is going to get freed.
Finally, the idea of setting a variable to null has some merit in certain circumstances (although it's not necessary most of the time, as you pointed out). If you have code like this:
int [] bigObject = new int[1000000];
while ( somethingReallySlow() ) {
doStuff();
}
Then bigObject may not get freed for a long time.
Just the fact that they're discriminating based on version is already pretty bad. They ought to just send you a SMS with a warning message every week or something.
Any LGPL-licensed code can be converted into GPL per section 3 of the LGPL v2.1, so the effect should be the same as dual-licensing LGPL/GPL. In practice, this means the work as a whole must be used as GPL, but you could potentially take another part of the code that doesn't rely on the GPL library and reuse that in a LGPL'd project.
IANAL though.
It doesn't matter if it costs $300. I'm sure they'll be able to find people willing to pay that much as long as it's not complete garbage.
I mean, if you look at amBX, it's basically a bunch of glowy LED lights and a speaker system, and it runs in about the same price range.
I think part of the appeal of the iPhone to developers (not me, I don't like the iPhone personally) besides the large market, is that when you develop an app, it looks exactly the same on every iPhone. You don't have to worry about screen size or hardware capabilities. There's some divergence now since the iPhone 3GS is considerably faster than the older iPhones, but it's not nearly as big a difference as other phones.
Android has a similar problem to the old JavaME model. You have to design for the lowest common denominator. It's a little better, because JavaME had a really low common denominator (dumb phones with limited memory and CPU) while Android is aimed at smartphones with a touchscreen interface.
I think it's because retail products take up physical space, so there's an incentive to clear inventory. With digital distribution, they can sell as many or as few copies as they want in order to maximize revenue.
I can imagine that for some companies, they don't want to mention the percent to avoid revealing their actual sales figures -- since the total amount of money donated will probably show up in the charity's public disclosures. Also, it lets them change it according to how generous they're feeling at the moment and their financial situation.
It would be nice if they at least announced the total amount raised, which gives you a reasonable sense of whether it's a significant amount of money for a company of their size, or if the entirety of the donation turned out to be a check for $1000 for a nation-wide promotion.
I'd guess that beyond just being computationally difficult, it'd look kind of weird just because of the latency and the fact that character movements are not perfectly smooth/natural.
The most annoying thing about bots in versus is that they pretty much refuse to help get a special infected off you until you've already lost most of your internal organs. They stand right next to you and watch you squirm for about 5-15 seconds.
That's got to be more than just stupidity. I think there's just some variable somewhere to make them completely ineffective at saving people.