Package managers are most certainly the best option available but they do need refined still.
Package managers are great for one thing: keeping programs up-to-date. It just so happens that users don't really care about this.
They suck for:
1. Collecting the programs you want installed. Sure, you can make a folder with the.deb's for programs you want, but they are instantly out of date with what he package manager thinks is current. And all hell breaks loose if you force it to install an incompatible version of something. If you're really technical you could create a script to apt-get the programs, assuming they are all in the default repos and the names never change.
2. Installing old versions. You basically can't. It'll complain that you have 'lib-yyy.5.97' but MUST have 'lib-yyy.5.96'. If you actually get it installed, you have to monkey with symlinks to get it to even try to run.
3. Controlling your process. If you're a company, you want to have control over the release process. To do this you need to set up repositories for debs, rpms, whatever, and somehow get these added to people's package managers. Or you create a stand-alone.sh style installer and confuse user.
Package managers are only good in linux because everything changes so much, it's such a pita to get older software working, and most software currently is free and can be packaged by the distro. But the user doesn't care about any of this! The windows model of installers is actually better match to what users actually want, and the Apple model of applications being folders that contain everything they need is even better still. Package managers are basically terrible in comparison.
It's not necessarily a contradiction. You can have a microkernel architecture without the memory protection for instance. It would be essentially the same as a stable ABI for drivers. Solaris has a stable ABI for drivers.
Troll or not, the linux kernel does have more problems than most unix (it also has more features though). Take for instance the recent problems with kernel ftrace, which destroyed e1000(?) bios and bricked cards around 2.6.27 or so; I don't remember anything similar to this with solaris dtrace and it's doing far more. The reason is that solaris has actual paid engineers, code reviews, and controls in place.
I see a lot of uninformed people assume the linux kernel is always awesome for no other reason than because it's linux. After doing a bit of kernel programming for 5+ years now I see that there are some parts to linux that are actually really bad. Take [di]notify for instance. It's hard to come up with a worse API for being notified of file changes. Both Microsoft and Apple for about a decade now have had much better file notification than current linux has now.
I see lots of students using netbooks, but... it's always Windows.... IMO Asus really dropped the ball by not getting the quality of their Linux configuration right.
I don't blame Asus, and here's why.
1. The linux systems are too fragile in that they require lots of modifications over time. Should Asus have written a linux tool to change the core clock frequency, it would have worked for only a couple of system updates / months, if that. Instead they made the utility for Windows and it works on several versions and will continue to work despite any number of Windows Updates or other software installed. Five years from now, the same program they wrote for Windows to change the clock speed will still work.
2. Firefox simply blows on linux. I've seen xul run faster on Windows over VNC than running native on linux systems. I assume the linux UI gets no attention since it has an effective monopoly; you don't choose firefox on linux, it's the only sensible choice. Firefox is basically the IE5/6 of linux.
I'd hate for people to get the impression that Linux is slow and crappy, simply because netbooks are underpowered to run Firefox/js/flash
The netbook is underpowered to run Firefox in linux. In Windows, firefox is plenty snappy and you can even use Chrome if you can live without plugins.
Linux kernel: 9 million lines of code Hotspot: 250k lines of code
So even if you include hotspot, which is currently the ultimate in JIT, you get 1/36th as much code that must be correct. Also, code in the JIT is far less likely to be exploitable even if more likely to contain errors. If you instead choose to use a llvm compiling a simpler language, then the amount of possible bad code is reduced even further. On top of that, you could run the JIT part mostly in a separate memory space so that to do damage you have to get it to result in bad code rather than just failing or aborting.
But the real problem with microkernel is that the benefits are so few compared to the costs. The only reason to have protected 'servers' is because the servers are written in a C-like unsafe language. It's basically a problem of two wrongs, C and separate protection spaces, not making a right -- but nobody should expect them to.
What would work great would be a kernel that includes C/asm and also a typesafe part that protects from invalid pointers and memory. The vast majority of the kernel is not performance critical and these parts can and should be written in a typesafe language (not necessarily requiring a JIT compiler). This enables a mostly seamless interaction with C/asm parts while protecting against errors. It's BoBW.
Ok well a while back I was on a team that placed 3rd in ACM regionals and I was 93% on topcoder and still rising pretty fast after just a couple weeks. This was the practice team; our #1 team placed 4th internationally that year irrc.
1. If you know the problems ahead of time then you'll win. End of story. I'm not saying the Russians or Chinese had the problems ahead of time, but this is the nature of the competition.
2. Our practice was to get up on Sunday morning at 8 or 9am (depending on football schedule?) and redo old problems from regionals and finals. This is what all high placing teams did to practice. The problems are simple, and you can pretty much instantly figure out the right approach. Deciphering the poorly-worded questions to figure out what the actual problem is, is another matter. I don't get up at 8am on a Sunday, sorry.;-P
3. For instance an asteroid early warning system, with gotcha data of asteroid first seen at coordinates 0,0 and last seen at 0,0. One team put in a clarification for this and was not answered directly ("refer to the problem description" or something like that). This is gotcha test data that has no bearing on the actual solution to the problem. This data is withheld to make the problem harder, when a good competition would have harder problems.
4. Wrong. When you program crashes they could return you the test data it crashed on for instance. You're already penalized 20(?) minutes for each incorrect submission, so the only reason not to do this is to put up fake walls to solving the problem.
You don't have to take my word for it, but ask other people who have actually done this competition instead of just armchair quarterbacking it.
1. A good team just getting its hands on the test data beforehand, let alone the problems, will win hands down. The two countries most likely to do this IMO, China and Russia, are the winner and runner up. I don't mean to presume the worst or disparage their programmers, but I certainly don't trust the ACM to secure this very well.
2. The problems are not unique and are usually very simple. The competition rewards people that memorize past problems and solutions, and can regurgitate the code quickly.
3. Important test data is withheld, meaning there is a lot of time wasted by asking for clarifications. And answers to clarification are often mysterious as to hide important 'gotcha' test data. The ACM acts like if they give out actual test data then the programs will be hard-coded. But that's only the case if you give out all of the test data. If the test input is "3.3" you have other input that is "3.4" that you don't give out and then they have to actually solve the problem.
4. Failures are purposely made hard to correct. If your program is not 100% correct the result is "Invalid output" or "Crash". You have no idea what is wrong, so you just have to guess at what is not correct. In some cases the test data itself has been wrong (not valid according to problem description), and invalid programs have been accepted because they made the same wrong choices as the people creating the test data.
Some people will say those things I listed are just part of the challenge. Ok, fine, but in the end they make the competition about the ability to recite code and to anticipate inputs; if you expected thinking to be involved you're sorely mistaken. As a measure of what I think most people would consider programming skill this competition is bunk.
yes, true, I have a fiancee; I'm an atypical nerd that has managed to develop a few social skills... You can count the number of companies in that class on two hands, tops
If you were a real nerd you would have known you can easily count to 1024 on two hands. Counting to 59049 is pretty easy as well. A true nerd would have specified how many bits were sufficient to enumerate that number of companies. -- I knew von Neumann; von Neumann was a friend of mine. You, sir, are no von Neumann.
The unique ID is just a random number. How does that let Google tie your IP address to an advertising profile better than, say, a regular cookie?
Say the logs look like this:
17.205.76.119: update request from uid 229782969 17.205.76.119: log in to gmail as Joe User 17.205.76.119: request 1x1 dissident-456713.png 17.205.76.119: request google-analytics for site americanidol.com continues for 1 week 17.205.76.119: update request from uid 229782969
Since there were no other updates from your IP they know you aren't behind a proxy. They can tell with high probability that everything done from that IP during the week is attributable to you. For advertising purposes they might not even care if it is not entirely correct as long as it makes their ads more targeted. Even if they can say there's an 80% probability that user from this IP were "Joe User-ish" that helps them.
In reality google might do nothing negative with this information, but they could, and if this were China for instance Joe User might be linked as dissident 456713 and locked up. Because of a random number. The reality is that "non-personally identifying information" or "anonymous usage data" is almost always uniquely attributable to you.
If you were building an auto-updater, you'd probably be interested in knowing how many people had your app installed too. That way you know if people uninstall the app you're doing something wrong!
If I were building an auto-updater I would have a URL for instance "http://my.domain.com/currentVersion/productName" that just returns the current build ID.
If I were building a spyware I would have the updater send me other information, like an ID or a timestamp, or a user name, or whatever. If I had the world's largest commercial database on user this would be a tempting option.
If I wanted to know if people were uninstalling my app I might have it contact my site on uninstall, or better give the user a dialog asking why they are installing it and the option to send a comment.
Because if you install chrome and use it only once, with a background service google still gets regular update checks from your IP address.
Using timestamps or unique IDs or other anonymous usage data they can then group your site accesses into a unique profile. Even if they can't map it to a specific user they get an anonymous profile from it, so they know the site access information they gather in other ways is from the same user instead of multiple users.
Google wants an auto updater so badly because it allows them to gather more information on you. Why else would it have ever included a unique identifier? There is ZERO reason for a updater to identify anything besides installed product (if that), not even the currently installed version. Any intelligent person knows this, and google is a cut above. That means it was certainly their intention to collect more information through updates. And why wouldn't google do this?
Even today there are a lot of people that never log in to a google service. Google updater is really about identifying and categorizing these users, for better ad targeting or accounting or whatever purpose. All they have to do is install any one google product, even if they never use it. If you log in to google often they already have a great profile on you.
The update check lets them tie your IP address with their profile on you. Many people have 'stable' IP addresses, even though they are using DHCP they get the same address. The updater lets google determine this, or that a person's IP address isn't stable.
The simplest, most effective, and most obvious method to track individuals is with a unique ID. This was the first method updater used (ie, google thinks everybody else are idiots). This provides a direct IP to user mapping at ever update.
Next, they might try a last-update-at timestamp. Even at a second resolution with list of installed products this lets them easily map IP to user with a high degree of accuracy. But they'd probably try something to tighten this up, like return a time cookie from the server and store it for next time.
If they can't do a direct mapping like this, they'll try something more sneaky like 'anonymous usage data' that then can just look up in their database... how many users accessed gmail exactly 327 times and groups 136 times in the last week? Repeat until it narrows down to one.
So the updater software itself is irrelevant. The only issue is what data does it send and does it run often enough to lock down your IP, or determine how your IP changes over time. This is important because tracking images, google-analytics, ad-words can determine your IP as you visit sites.
I'm sure they cut off the internet entirely after +$75, then you can call them up and switch to unlimited for $150 on top of that (not pro-rated or anything halfway sensible).
'Friends and family' websites. Get unlimited Gb to your 5 favorite websites. You can choose Google,/., Reddit, Engadget, LKML while little Suzie can choose MySpace, Facebook, Digg, Twitter, AmericanIdol.
the mercury issue. Which is 1/10 the mercury put out by burning hydrocarbons (especially coal) for powering incandescent lamps. Yes, the mercury from CFLs is mercury in your house, and the other kind of mercury from the generators powering incandescent lighting is just in the air you breathe in your house.
The mercury put out by a coal plant is diluted by the entire environment, which is very much larger than your home. So even if coal power was putting out a thousand times more mercury it would be to your advantage, as an individual, to use incandescent lighting. Worse for the environment, better for you.
Speaking of conscience, why is it that Slashdot is an oft-repeat offender in spreading anti-CFL nonsense?
Personally, I have a long-standing beef with fluorescents because I can see the flicker in 120hz or 60hz lights, which are still used all over the place in office buildings. About 1/4th of the programmers here have the building lights off and their own incandescent lamps for that reason.
CFLs 'fix' some of these issues, but many still remain:
1) They hiss at near the limit of hearing. Having an electronic lamp hiss at you is somewhat disturbing. If you can't hear this hiss anymore then you wouldn't understand. 2) They release a lot more UV then widely known. For intance, in just a year of using a CLF in a lamp I had, the plastic sheath over the bulb housing was completely denatured. 3) They still flicker in some cases, like at startup and near the end of their life. 4) They don't tolerate unclean power, or humid or really dry environments (just like any electronic device), or fully enclosed fixtures... they die earlier. 5) The quality of light and product is hit-or-miss. Some people in the comments even said "learn which brands are good". No thanks, if I but an tungsten or halogen incandescent it is *always* good and I can buy it in any store without having to shop around. The pro-CFL lobby doesn't include the cost of driving to Lowes which is 20 miles father away here than Home Depot.
And lastly... I don't accept the false choice that we have to use CFLs with all their faults because our power generation pollutes. 'Solving' a problem like coal power by using less of it isn't a solution at all, it's just an optimization. We will continue to use more and more power, and the only actual solution is to create alternatives to coal power that are cheaper. For instance, plug-in hybrids are going to use a lot of power and it's going to be generated by coal unless we solve the actual problem.
Pages can have multiple styles... although pretty much no sites do, since they'd have to support another style. But you can set 'simple style' in your/. account prefs... then you get black bars instead of colored ones;-(
The 10x longer is because even though there is no style the javascript is still running to abbreviate posts and whatever tf else it does. You can disable javascript using the noscript addon. Supposedly that works in seamonkey too.
Also, google maps works just fine as long as you disable style AND javascript (the url will have &output=html). Not sure why anybody would use the non-javascript view though...
this is one reason I still use antique Netscape 3 here -- it doesn't do CSS or JS, so all I see is plain text, rendered almost instantly.
In firefox:
View -> Page Style -> No Style
Probably you can do this automatically with greasemonkey or something. Noscript will disable all javascript, or only js you want.
My internet machine is a P3 (albeit with gobs of RAM)... If the site's "improvements" ever get to where I can't use NS3 to read and post, I'll have to give up Slashdot -- it simply won't be worth the time or the eyestrain
'Here's a nickel kid. Get yourself a better computer.' Also, nobody else can read Idle stories either...
I would use Fedora over Ubuntu any day, if not for two things:
1) Have to 'reinstall' to upgrade to next version. I know there's a way to live upgrade, but it's still 'at your own risk' right? 2) openbsd-style netcat. Seriously, why reimplement netcat and change all the options? Hobbit forever.
I have experience working with many distros, and Fedora is far better in terms of quality and security in my experience than anything else. Selinux is great... but god forbid if you have to maintaining the policy yourself. Fedora's a little harder to get codecs, but it's not a huge deal. Also they don't do retarded things like rebranding firefox.
Some tips on netbook power. Hopefully/. will correct anything wrong here:
1) Underclocking can have huge savings... as much as the backlight being on/off. I don't mean using cpufreq to change processor frequency... the power savings apparently comes from the ram and slowing down the ridiculously bad Intel GMA945. This is generally easier on XP since the OEM will have some software to do this, and nothing pre-packaged exists in Linux afaik.
2) Use a plain background and plain graphics... no gradients or pictures. GMA can use run-length encoding to compress the display memory on a line-by-line basis, and if the line hasn't changed the display uses the compressed version.
Somebody check my numbers... assuming 666 fsb, that's 666Mhz*4 bytes per second. The display might use 1024*600*3 bytes and if it refreshes the display at 60 fps, the shared memory for the display uses:
(1024*600*3*60) / (666*Mhz*4) = 15% of fsb time
That must be wrong, because at high res it would be using all the time. But I don't know what assumption is wrong... but anyway if you can compress by say 80% by using solid colors (or vertical gradients) then you can save some power and make the system somewhat faster. This might have to be turned on with the driver, idk if linux driver can do this.
3) Some USB devices use a lot more power than you'd expect. For instance a standard USB laser mouse can use a watt from various things like having USB polling it frequently.
4) As far as I can tell from reading the web, RAM power is basically how many modules you have installed not how much memory is on them. Maybe it's based on the number of chips? Anwyay it looks like upgrading memory should increase battery life by reducing disk access. So for instance if the system has low ram, like 512mb you might see disproportionately better power on linux since it generally uses less ram, so less hd activity.
5) It's almost not worth it to put the hard disk to sleep. Modern laptop drives you might save.2-.4w over just idle, but spin up might take 5w. So telling hd to spin down every 3 min for instance might actually use more power.
This could give CPython the performance edge over Jython, but it still has a way to go to catch up to Java.
Except that jdk 1.7 is getting all sorts of improvements that will help with Jython speed... like a dynamic method call opcode and stack-allocated objects.
So it's doubtful that llvm python will be faster than Jython, or at least not for long.
Compressors turn off while you're accelerating hard, so you don't notice. Try turning it on/off while doing a slower acceleration... on every car I've had it feels like molasses when the compressor is running. Way more than the couple % you're claiming. Did you mean 5 hp overall for a trip, including when it's off?
Only when those numbers got lower did people consider them acceptable for gaming, as the ghosting effect has become almost unnoticable with 6ms response time monitors.
Response time they are talking about is how fast the pixel changes, not the time between the computer sending the pixel to the time it is displayed. The monitors usually get small response times by overdriving the pixels so that they change faster... but this causes them to overshoot the target value, so the monitor buffers a few frames worth of pixel values so it can reduce this (by knowing the 'future' value of the pixel). A lot of mainstream monitors actually delay the image by ~50ms just to get your 3ms response time. It's unbelievable, but true.
Also in a normal online game the time you press the button at your end means nothing... what matters is when the button press event gets to the server. So as long as the rendering server is in the same line of hops (ie co-located with ISP) to the actual game server then you won't have any more than a couple ms extra lag.
So really I don't see lag as a real objection to this. I don't see bandwidth as a huge problem going forward either... lots of people already have fiber going to their house these days.
Instead of normal online game lag, you have lag between you actually pressing a button and the game responding at the server.
Not necessarily. A LOT of lcd computer monitors have 'input lag' of say 50ms (meaning the computer sends the image to the monitor but you don't see it for 50ms after that) whereas lcd tvs don't, and few people complain. Presumably if the game servers are co-located with the ISP you could get lag much smaller than that.
Slashdot Mirror
Package managers are most certainly the best option available but they do need refined still.
Package managers are great for one thing: keeping programs up-to-date. It just so happens that users don't really care about this.
They suck for:
1. Collecting the programs you want installed. Sure, you can make a folder with the .deb's for programs you want, but they are instantly out of date with what he package manager thinks is current. And all hell breaks loose if you force it to install an incompatible version of something. If you're really technical you could create a script to apt-get the programs, assuming they are all in the default repos and the names never change.
2. Installing old versions. You basically can't. It'll complain that you have 'lib-yyy.5.97' but MUST have 'lib-yyy.5.96'. If you actually get it installed, you have to monkey with symlinks to get it to even try to run.
3. Controlling your process. If you're a company, you want to have control over the release process. To do this you need to set up repositories for debs, rpms, whatever, and somehow get these added to people's package managers. Or you create a stand-alone .sh style installer and confuse user.
Package managers are only good in linux because everything changes so much, it's such a pita to get older software working, and most software currently is free and can be packaged by the distro. But the user doesn't care about any of this! The windows model of installers is actually better match to what users actually want, and the Apple model of applications being folders that contain everything they need is even better still. Package managers are basically terrible in comparison.
The real question is when Wolfram Alpha will go beta.
It's not necessarily a contradiction. You can have a microkernel architecture without the memory protection for instance. It would be essentially the same as a stable ABI for drivers. Solaris has a stable ABI for drivers.
Troll or not, the linux kernel does have more problems than most unix (it also has more features though). Take for instance the recent problems with kernel ftrace, which destroyed e1000(?) bios and bricked cards around 2.6.27 or so; I don't remember anything similar to this with solaris dtrace and it's doing far more. The reason is that solaris has actual paid engineers, code reviews, and controls in place.
I see a lot of uninformed people assume the linux kernel is always awesome for no other reason than because it's linux. After doing a bit of kernel programming for 5+ years now I see that there are some parts to linux that are actually really bad. Take [di]notify for instance. It's hard to come up with a worse API for being notified of file changes. Both Microsoft and Apple for about a decade now have had much better file notification than current linux has now.
I see lots of students using netbooks, but ... it's always Windows. ... IMO Asus really dropped the ball by not getting the quality of their Linux configuration right.
I don't blame Asus, and here's why.
1. The linux systems are too fragile in that they require lots of modifications over time. Should Asus have written a linux tool to change the core clock frequency, it would have worked for only a couple of system updates / months, if that. Instead they made the utility for Windows and it works on several versions and will continue to work despite any number of Windows Updates or other software installed. Five years from now, the same program they wrote for Windows to change the clock speed will still work.
2. Firefox simply blows on linux. I've seen xul run faster on Windows over VNC than running native on linux systems. I assume the linux UI gets no attention since it has an effective monopoly; you don't choose firefox on linux, it's the only sensible choice. Firefox is basically the IE5/6 of linux.
I'd hate for people to get the impression that Linux is slow and crappy, simply because netbooks are underpowered to run Firefox/js/flash
The netbook is underpowered to run Firefox in linux. In Windows, firefox is plenty snappy and you can even use Chrome if you can live without plugins.
Let's look at some numbers:
Linux kernel: 9 million lines of code
Hotspot: 250k lines of code
So even if you include hotspot, which is currently the ultimate in JIT, you get 1/36th as much code that must be correct. Also, code in the JIT is far less likely to be exploitable even if more likely to contain errors. If you instead choose to use a llvm compiling a simpler language, then the amount of possible bad code is reduced even further. On top of that, you could run the JIT part mostly in a separate memory space so that to do damage you have to get it to result in bad code rather than just failing or aborting.
But the real problem with microkernel is that the benefits are so few compared to the costs. The only reason to have protected 'servers' is because the servers are written in a C-like unsafe language. It's basically a problem of two wrongs, C and separate protection spaces, not making a right -- but nobody should expect them to.
What would work great would be a kernel that includes C/asm and also a typesafe part that protects from invalid pointers and memory. The vast majority of the kernel is not performance critical and these parts can and should be written in a typesafe language (not necessarily requiring a JIT compiler). This enables a mostly seamless interaction with C/asm parts while protecting against errors. It's BoBW.
Ok well a while back I was on a team that placed 3rd in ACM regionals and I was 93% on topcoder and still rising pretty fast after just a couple weeks. This was the practice team; our #1 team placed 4th internationally that year irrc.
1. If you know the problems ahead of time then you'll win. End of story. I'm not saying the Russians or Chinese had the problems ahead of time, but this is the nature of the competition.
2. Our practice was to get up on Sunday morning at 8 or 9am (depending on football schedule?) and redo old problems from regionals and finals. This is what all high placing teams did to practice. The problems are simple, and you can pretty much instantly figure out the right approach. Deciphering the poorly-worded questions to figure out what the actual problem is, is another matter. I don't get up at 8am on a Sunday, sorry. ;-P
3. For instance an asteroid early warning system, with gotcha data of asteroid first seen at coordinates 0,0 and last seen at 0,0. One team put in a clarification for this and was not answered directly ("refer to the problem description" or something like that). This is gotcha test data that has no bearing on the actual solution to the problem. This data is withheld to make the problem harder, when a good competition would have harder problems.
4. Wrong. When you program crashes they could return you the test data it crashed on for instance. You're already penalized 20(?) minutes for each incorrect submission, so the only reason not to do this is to put up fake walls to solving the problem.
You don't have to take my word for it, but ask other people who have actually done this competition instead of just armchair quarterbacking it.
1. A good team just getting its hands on the test data beforehand, let alone the problems, will win hands down. The two countries most likely to do this IMO, China and Russia, are the winner and runner up. I don't mean to presume the worst or disparage their programmers, but I certainly don't trust the ACM to secure this very well.
2. The problems are not unique and are usually very simple. The competition rewards people that memorize past problems and solutions, and can regurgitate the code quickly.
3. Important test data is withheld, meaning there is a lot of time wasted by asking for clarifications. And answers to clarification are often mysterious as to hide important 'gotcha' test data. The ACM acts like if they give out actual test data then the programs will be hard-coded. But that's only the case if you give out all of the test data. If the test input is "3.3" you have other input that is "3.4" that you don't give out and then they have to actually solve the problem.
4. Failures are purposely made hard to correct. If your program is not 100% correct the result is "Invalid output" or "Crash". You have no idea what is wrong, so you just have to guess at what is not correct. In some cases the test data itself has been wrong (not valid according to problem description), and invalid programs have been accepted because they made the same wrong choices as the people creating the test data.
Some people will say those things I listed are just part of the challenge. Ok, fine, but in the end they make the competition about the ability to recite code and to anticipate inputs; if you expected thinking to be involved you're sorely mistaken. As a measure of what I think most people would consider programming skill this competition is bunk.
yes, true, I have a fiancee; I'm an atypical nerd that has managed to develop a few social skills ... You can count the number of companies in that class on two hands, tops
If you were a real nerd you would have known you can easily count to 1024 on two hands. Counting to 59049 is pretty easy as well. A true nerd would have specified how many bits were sufficient to enumerate that number of companies.
--
I knew von Neumann; von Neumann was a friend of mine. You, sir, are no von Neumann.
The unique ID is just a random number. How does that let Google tie your IP address to an advertising profile better than, say, a regular cookie?
Say the logs look like this:
17.205.76.119: update request from uid 229782969
17.205.76.119: log in to gmail as Joe User
17.205.76.119: request 1x1 dissident-456713.png
17.205.76.119: request google-analytics for site americanidol.com
continues for 1 week
17.205.76.119: update request from uid 229782969
Since there were no other updates from your IP they know you aren't behind a proxy. They can tell with high probability that everything done from that IP during the week is attributable to you. For advertising purposes they might not even care if it is not entirely correct as long as it makes their ads more targeted. Even if they can say there's an 80% probability that user from this IP were "Joe User-ish" that helps them.
In reality google might do nothing negative with this information, but they could, and if this were China for instance Joe User might be linked as dissident 456713 and locked up. Because of a random number. The reality is that "non-personally identifying information" or "anonymous usage data" is almost always uniquely attributable to you.
If you were building an auto-updater, you'd probably be interested in knowing how many people had your app installed too. That way you know if people uninstall the app you're doing something wrong!
If I were building an auto-updater I would have a URL for instance "http://my.domain.com/currentVersion/productName" that just returns the current build ID.
If I were building a spyware I would have the updater send me other information, like an ID or a timestamp, or a user name, or whatever. If I had the world's largest commercial database on user this would be a tempting option.
If I wanted to know if people were uninstalling my app I might have it contact my site on uninstall, or better give the user a dialog asking why they are installing it and the option to send a comment.
Because if you install chrome and use it only once, with a background service google still gets regular update checks from your IP address.
Using timestamps or unique IDs or other anonymous usage data they can then group your site accesses into a unique profile. Even if they can't map it to a specific user they get an anonymous profile from it, so they know the site access information they gather in other ways is from the same user instead of multiple users.
Bait and switch would be just like these guys!
Google wants an auto updater so badly because it allows them to gather more information on you. Why else would it have ever included a unique identifier? There is ZERO reason for a updater to identify anything besides installed product (if that), not even the currently installed version. Any intelligent person knows this, and google is a cut above. That means it was certainly their intention to collect more information through updates. And why wouldn't google do this?
Even today there are a lot of people that never log in to a google service. Google updater is really about identifying and categorizing these users, for better ad targeting or accounting or whatever purpose. All they have to do is install any one google product, even if they never use it. If you log in to google often they already have a great profile on you.
The update check lets them tie your IP address with their profile on you. Many people have 'stable' IP addresses, even though they are using DHCP they get the same address. The updater lets google determine this, or that a person's IP address isn't stable.
The simplest, most effective, and most obvious method to track individuals is with a unique ID. This was the first method updater used (ie, google thinks everybody else are idiots). This provides a direct IP to user mapping at ever update.
Next, they might try a last-update-at timestamp. Even at a second resolution with list of installed products this lets them easily map IP to user with a high degree of accuracy. But they'd probably try something to tighten this up, like return a time cookie from the server and store it for next time.
If they can't do a direct mapping like this, they'll try something more sneaky like 'anonymous usage data' that then can just look up in their database... how many users accessed gmail exactly 327 times and groups 136 times in the last week? Repeat until it narrows down to one.
So the updater software itself is irrelevant. The only issue is what data does it send and does it run often enough to lock down your IP, or determine how your IP changes over time. This is important because tracking images, google-analytics, ad-words can determine your IP as you visit sites.
I'm sure they cut off the internet entirely after +$75, then you can call them up and switch to unlimited for $150 on top of that (not pro-rated or anything halfway sensible).
'Friends and family' websites. Get unlimited Gb to your 5 favorite websites. You can choose Google, /., Reddit, Engadget, LKML while little Suzie can choose MySpace, Facebook, Digg, Twitter, AmericanIdol.
This kind of bs shouldn't be allowed to happen.
the mercury issue. Which is 1/10 the mercury put out by burning hydrocarbons (especially coal) for powering incandescent lamps. Yes, the mercury from CFLs is mercury in your house, and the other kind of mercury from the generators powering incandescent lighting is just in the air you breathe in your house.
The mercury put out by a coal plant is diluted by the entire environment, which is very much larger than your home. So even if coal power was putting out a thousand times more mercury it would be to your advantage, as an individual, to use incandescent lighting. Worse for the environment, better for you.
Speaking of conscience, why is it that Slashdot is an oft-repeat offender in spreading anti-CFL nonsense?
Personally, I have a long-standing beef with fluorescents because I can see the flicker in 120hz or 60hz lights, which are still used all over the place in office buildings. About 1/4th of the programmers here have the building lights off and their own incandescent lamps for that reason.
CFLs 'fix' some of these issues, but many still remain:
1) They hiss at near the limit of hearing. Having an electronic lamp hiss at you is somewhat disturbing. If you can't hear this hiss anymore then you wouldn't understand.
2) They release a lot more UV then widely known. For intance, in just a year of using a CLF in a lamp I had, the plastic sheath over the bulb housing was completely denatured.
3) They still flicker in some cases, like at startup and near the end of their life.
4) They don't tolerate unclean power, or humid or really dry environments (just like any electronic device), or fully enclosed fixtures... they die earlier.
5) The quality of light and product is hit-or-miss. Some people in the comments even said "learn which brands are good". No thanks, if I but an tungsten or halogen incandescent it is *always* good and I can buy it in any store without having to shop around. The pro-CFL lobby doesn't include the cost of driving to Lowes which is 20 miles father away here than Home Depot.
And lastly... I don't accept the false choice that we have to use CFLs with all their faults because our power generation pollutes. 'Solving' a problem like coal power by using less of it isn't a solution at all, it's just an optimization. We will continue to use more and more power, and the only actual solution is to create alternatives to coal power that are cheaper. For instance, plug-in hybrids are going to use a lot of power and it's going to be generated by coal unless we solve the actual problem.
Pages can have multiple styles... although pretty much no sites do, since they'd have to support another style. But you can set 'simple style' in your /. account prefs... then you get black bars instead of colored ones ;-(
The 10x longer is because even though there is no style the javascript is still running to abbreviate posts and whatever tf else it does. You can disable javascript using the noscript addon. Supposedly that works in seamonkey too.
Also, google maps works just fine as long as you disable style AND javascript (the url will have &output=html). Not sure why anybody would use the non-javascript view though...
this is one reason I still use antique Netscape 3 here -- it doesn't do CSS or JS, so all I see is plain text, rendered almost instantly.
In firefox:
View -> Page Style -> No Style
Probably you can do this automatically with greasemonkey or something. Noscript will disable all javascript, or only js you want.
My internet machine is a P3 (albeit with gobs of RAM) ... If the site's "improvements" ever get to where I can't use NS3 to read and post, I'll have to give up Slashdot -- it simply won't be worth the time or the eyestrain
'Here's a nickel kid. Get yourself a better computer.' Also, nobody else can read Idle stories either...
I would use Fedora over Ubuntu any day, if not for two things:
1) Have to 'reinstall' to upgrade to next version. I know there's a way to live upgrade, but it's still 'at your own risk' right?
2) openbsd-style netcat. Seriously, why reimplement netcat and change all the options? Hobbit forever.
I have experience working with many distros, and Fedora is far better in terms of quality and security in my experience than anything else. Selinux is great... but god forbid if you have to maintaining the policy yourself. Fedora's a little harder to get codecs, but it's not a huge deal. Also they don't do retarded things like rebranding firefox.
Plus it's easier to just download OO.o than to find a pirate copy of Office.
Some tips on netbook power. Hopefully /. will correct anything wrong here:
1) Underclocking can have huge savings... as much as the backlight being on/off. I don't mean using cpufreq to change processor frequency... the power savings apparently comes from the ram and slowing down the ridiculously bad Intel GMA945. This is generally easier on XP since the OEM will have some software to do this, and nothing pre-packaged exists in Linux afaik.
2) Use a plain background and plain graphics... no gradients or pictures. GMA can use run-length encoding to compress the display memory on a line-by-line basis, and if the line hasn't changed the display uses the compressed version.
Somebody check my numbers... assuming 666 fsb, that's 666Mhz*4 bytes per second. The display might use 1024*600*3 bytes and if it refreshes the display at 60 fps, the shared memory for the display uses:
(1024*600*3*60) / (666*Mhz*4) = 15% of fsb time
That must be wrong, because at high res it would be using all the time. But I don't know what assumption is wrong... but anyway if you can compress by say 80% by using solid colors (or vertical gradients) then you can save some power and make the system somewhat faster. This might have to be turned on with the driver, idk if linux driver can do this.
3) Some USB devices use a lot more power than you'd expect. For instance a standard USB laser mouse can use a watt from various things like having USB polling it frequently.
4) As far as I can tell from reading the web, RAM power is basically how many modules you have installed not how much memory is on them. Maybe it's based on the number of chips? Anwyay it looks like upgrading memory should increase battery life by reducing disk access. So for instance if the system has low ram, like 512mb you might see disproportionately better power on linux since it generally uses less ram, so less hd activity.
5) It's almost not worth it to put the hard disk to sleep. Modern laptop drives you might save .2-.4w over just idle, but spin up might take 5w. So telling hd to spin down every 3 min for instance might actually use more power.
This could give CPython the performance edge over Jython, but it still has a way to go to catch up to Java.
Except that jdk 1.7 is getting all sorts of improvements that will help with Jython speed... like a dynamic method call opcode and stack-allocated objects.
So it's doubtful that llvm python will be faster than Jython, or at least not for long.
Compressors turn off while you're accelerating hard, so you don't notice. Try turning it on/off while doing a slower acceleration... on every car I've had it feels like molasses when the compressor is running. Way more than the couple % you're claiming. Did you mean 5 hp overall for a trip, including when it's off?
Imagine a beowulf cluster of these imagining a beowulf cluster of these!!
Only when those numbers got lower did people consider them acceptable for gaming, as the ghosting effect has become almost unnoticable with 6ms response time monitors.
Response time they are talking about is how fast the pixel changes, not the time between the computer sending the pixel to the time it is displayed. The monitors usually get small response times by overdriving the pixels so that they change faster... but this causes them to overshoot the target value, so the monitor buffers a few frames worth of pixel values so it can reduce this (by knowing the 'future' value of the pixel). A lot of mainstream monitors actually delay the image by ~50ms just to get your 3ms response time. It's unbelievable, but true.
I believe this page explains input lag pretty well.
Also in a normal online game the time you press the button at your end means nothing... what matters is when the button press event gets to the server. So as long as the rendering server is in the same line of hops (ie co-located with ISP) to the actual game server then you won't have any more than a couple ms extra lag.
So really I don't see lag as a real objection to this. I don't see bandwidth as a huge problem going forward either... lots of people already have fiber going to their house these days.
But it's still a dumb idea. ;-P
Instead of normal online game lag, you have lag between you actually pressing a button and the game responding at the server.
Not necessarily. A LOT of lcd computer monitors have 'input lag' of say 50ms (meaning the computer sends the image to the monitor but you don't see it for 50ms after that) whereas lcd tvs don't, and few people complain. Presumably if the game servers are co-located with the ISP you could get lag much smaller than that.