The graphs shown in TFA indicated a 22.2x performance increase in 'function call' 37.5x increase in 'global loop', and 20.8x increase in 'empty loop'.
Then, they turn around and show a Sunspider performance boost of 1.8x - which is still awesome, but nowhere near the factor of 'twenty to forty' that is being carelessly bandied about by those who appear to misunderstand what is being represented.
What the PP seems to suggest is 'don't interpret and then JIT the slow parts, JIT everything'. His rationale is that the time wasted interpreting the code in order to figure out what needs optimizing makes up for the time spent optimizing everything.
For example, if your inner loop takes 3 seconds to execute, the JIT compiler will see that it's taken 3 seconds, and optimize it - if it ever runs again. If your code only takes 4 seconds to run, then 75% of your time is spent in the unoptimized inner loop.
Instead, he seems to propose that you optimize everything immediately, and then execute it. If it takes 1 second to optimize and you can shave 2 seconds off your inner loop in this case, you've saved 1 second overall. If your inner loop takes 9 seconds, you save 5 seconds overall. In essence, pre-compiling pays for itself in most cases.
At least, that was what I got out of it, though I'm open to correction.
Well, if the Mozilla folks come up with a MIME-type for compiled Javascript (e.g. text/x-moz-pc-javascript), then they can send that in the 'accept' header when requesting Javascript files, and then the server will know to send the Firefox precompiled version. WebKit could use text/x-wk-pc-javascript, and the server could send that.
Moving to other languages, however, would be tricky since it's unlikely that the (distressingly common) IE6 users could cope, resulting in having to at least write it in Javascript once.
Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.
They don't need your relay. If they're running on your machine, they can fetch their payload and then start sending it out through your local MTA or configured SMTP server. If you can send e-mail, so can they.
Yes, but without access to the system FF folder, that plugin will go in your per-user plugin directory, and will only run for you. So only your passwords will be stolen, and not those of anyone else on the computer.
Given that most computers running Firefox these days are single-user systems, whether running Linux, OS X, or Windows 98.
Then consider Linux systems. Most systems these days are set up with sudo access, as is OS X. All the bug has to do is watch to see when you run sudo yourself, and then bam, it has a (usually) five-minute window to run itself as root and infect the rest of your system.
It can also grab your ~/.ssh/known_hosts and then reach out to those to see which ones accept your private key; install itself there, and, again, watch for sudo access. It's not hard for someone to go from there out to infecting every machine you have access to, and root on every machine you have root on, and potentially every system that every user on that system has access to, and so on, and so on.
So we should have the same freedom on phones as we do on computers.. Makes sense, except that that flexibility also has consequences, and I can't wait to see the first version of McAfee Antivirus or Spysweeper for Android.
See XKCD for another view on the whole 'needs protection' issue.
The problem is that the RTT to Mars can be as high as (about) 2600 seconds, and I don't know any server that's going to wait 45 minutes for a reply, or any client that will wait 45 minutes for an answer from the server. Keepalives and your suggestion (what basically amounts to cache seeding or push prefetching) are great, but on top of a protocol like HTTP it doesn't make sense.
Heck, even TCP requires a SYN, ACK/SYN, ACK handshake, which means that even opening a TCP connection could take a little over an hour, plus another 20 minutes to get the data for your reply. Not very sensible, IMHO. A simple HTTP request ('Hey, can I have/index.html?') would take an hour and a half to get a reply. Not very sensible.
Well as Windows 98 didn't have SP2, I'm assuming you mean XP...
My cable provider blocked broadcast packets, so no one in our neighborhood could see anyone else any better than the rest of the world could see you, which was good. Broadband routers only help because they provide firewalling (a NAT necessity); the same could be done on new routers using IPv6; just have the router block incoming connections by default, and allow specific ports using... well, whatever protocol comes up. NAT-PMP seems oddly named for that, but it should work, as should UPnP.
For an anecdote to compliment your complaint about viruses on Windows, a professor at my university once had his computer plugged into the network while installing Windows. It turns out Windows brings up the network during the install process. End result, his computer was infected with blaster before he was even done installing Windows. Pretty sad.
Are you having the *new* 3G issue? Because the one thing that seems (anecdotally) to be in common for all those affected that I've heard from is an old SIM card (i.e. not the one that came in the box).
People who have the 'I can't get on the 3G network' issue have reported their problems go away when switching to the new SIM. Maybe that's worth trying?
That strikes me as what we in the industry call 'a recipe for disaster'. So how long until we see the first security hole that lets the payload replace the dialler and home screen (and maybe the contacts app) with apps that steal all your shit?
You can natively compare two v4 addresses by using a == b (which will translate into a single assembly instruction). You cannot do that on a 129 bit data item. Your choices are - memcmp, or defined operation (compare first 4 bytes, then next 4 bytes, then next, then next:) ). This is inefficient, prone to error and makes code less maintainable.
Well this might be overkill, but most SIMD units I've seen or dealt with can handle up to 128 bits of data at once - meaning that a simple vectorized function can compare an IPv6 address in a single instruction, so...
In regards to NAT, you seem to suggest that NAT is a natural, organic evolution from IPv4. I would argue that NAT is actually more like a disease - perfectly natural, and entirely undesired. NAT seems to me like chemotherapy is to cancer, actually. We have a problem, and we have a solution - and the solution is, in some cases, worse than the disease. So instead of just having cancer, we now have cancer and radiation sickness. Where the analogy fails is that things aren't going to get better - they'll just keep getting worse. All the radiation therapy is doing is making the pain last longer. IPv6 is the surgery that can excise the tumor entirely, and prevent the pain that we're going through from being necessary at all.
Some things are organic, and some things are artificial. Sometimes, you have to understand that the natural will need to be replaced by the artificial, because the natural is failing, and it's going to take the host with it.
Also, any trolls pulling out the "yuo cant has teh firawalls withouts teh NAT!!!11" crap can please not respond to this as packet filtering does not in any way require NAT. (Not directed at parent post, just tired of trolls and ignorant fools always using that argument).
Well said, a point most people tend to miss when whining about IPv6. If you don't want people getting into your network - well, then say so! It's phenomenally trivial to set up a firewalling rule saying 'No inbound connections are allowed to this address range'. Using VLANs, you could easily subdivide your network, such that any systems you want accessible are on one subnet on one VLAN, and any hosts you don't are on another subnet on another VLAN.
Some people argue that 'Oh, now people outside of my network know that a certain host is the one connecting!' Well, yes, that's true. However, all they know is an address in an address range. They don't actually know anything more than 'A host from this company is connecting', which is what they know now. Them being able to trace individual hosts can be a huge benefit for network admins, because now if someone is getting a lot of traffic from my office, I know exactly where to look without having to check the switch's logs (especially since the switch for our office is managed by someone else).
Do you want outside organisations to find out that the person accessing their webserver is terrance.phillips.accounting.office.internal.company.com ? Well no, of course not - so don't use descriptive revDNS. Workstation-v1104.company.com would work just as well for all purposes, but not expose information to the outside world.
So now we have a system that is as secure as NAT is, as 'private' as NAT is for all intents and purposes, and which can provide even more security up the pipe because the remote host can say 'Hey, you're not from user2023's IP address, so I'm not going to accept your session cookie'.
Oh, and this is anecdotal, but I've found in the past that connecting through a tunnel broker, and then connecting via IPv6 to an IRC server through that tunnel, consistently had less latency than connecting to the same server over IPv4 from the same host (obviously not through the tunnel). Take THAT, overhead haters!
I asked my favourite colocation/networking company, Peer 1 Networks, what their stance was on IPv6. The answer I got back (from their best salesperson) was that they were taking a 'wait and see' attitude. They had no intention of being first, being innovative, or for that matter, doing anything until they saw what other people were doing. There's no money in it, so why bother? IPv6 doesn't get you anything but additional infrastructure that a lot of people these days don't yet fully understand.
I was disappointed, but I don't blame them. It would be great if they did, but honestly, while the tech geek in me wants it, the pragmatist knows that it's not really that useful... At least, not yet.
Still, I pointed out to her that when it IS useful, it would be nice to be there already. She agreed on that, at least in principle.
How about authenticated web apps? IPv6 secures traffic from the user to the cloud. That's something Apple has reason to push with MobileMe: "look at us, we have IPv6 security."
Put another way - 'Look at us, all of your traffic to us goes through some third-party router, and may well be getting sniffed on the way. If a hacker gets them, they win!'
I know that's not true if SSL is used (and MobileMe does use HTTPS for push updates, somehow), but the average user doesn't know that.
Mexican ISPs already NAT a large portion of their subscribers. End result? When someone does something bad (e.g. is being an asshat on IRC, a problem for me back when I was an IRC server admin), you can't narrow down to a specific person.
In my IRC example, banning one IP address would kick off up to a hundred users - pretty insane, considering our net only had a 2400 user record, and half of them were from Mexico. Suddenly, I have 99 pissed-off users, and one asshat who just hops on a proxy instead.
(Of course, since all of these users were teenagers, in the same neighbourhood of the same city and went to the same school, the easiest solution discovered by those of us dealing with Mexican asshats was to tell everyone who it was that had gotten them banned, and reassure them that after the ban expires (usually an hour to start), they won't get banned again unless the asshat acts up again. I'd imagine I caused a lot of threats, angry IM chats, and possibly savage beatings.)
But... do you tie it to the roof then, like with a small truck? I'm confused. I was going to buy a sofa from Ikea's website, and I need to know how to get it home. If I can't dump it in the back of the intertruck, what are my other options?
I've been thinking about this sort of thing for ages, mostly in conjunction with ponderances on things like interplanetary news.
Between Earth and Mars, you can't FTP - the RTT is so long that the protocol-specified maximum timeout expires before a response can be returned to you. Obviously loading up a web page would be a senseless waste of time. We would need a way of transporting or requesting information in batches in order to effectively communicate things like news between planets.
In my mind, while at university, I envisioned a system consisting of 'packages', which contained some data or subset of data. It could be an entire website (which, for many companies, is merely a brochure, menu, etc. anyway), part of a website (an updated to a company's product information pages, for when e.g. Apple ships a new iMac), or even a single file - a press release, news clip, etc.
Each parcel of information would belong somewhere in a heirarchy. You could start with 'Apple' and grab their default content (say, most of what's on their website at first glance), and then delve deeper into areas like 'support', 'developer info', and so on. Those packages, while not necessarily retrieved by default, could be requested, and would slot into the heirarchy. Without them, you see that they're there and what kind of content is available; you can then request the content be updated, and when the 'package' arrives, you suddenly have access to that content as well.
Likewise, you could start issuing specific identification that computers could use to narrow down who you're looking for. Instead of www.apple.com, you could just do a search for 'Apple Computers' or 'Apple, Inc', and you would be able to find relevant information from (and about) the company. Because we can now uniquely identify business electronically, it's easy for someone writing a news article to 'tag' the article as being about Apple, Inc., and your client can do any associations you might want - stock updates, press releases (especially relevant press releases to the story), and so on, and whatever isn't local can be updated.
Obviously, this would require two things; firstly, a complete overhaul in the way the internet works; secondly, local (possibly hierarchical) caches wherever relevant, so that information doesn't need to be transmitted multiple times. Also, the caches can pre-fetch or be pre-seeded content ahead of time, so that (for example) major/popular news sites could send updates to their content in batches every hour/day/etc.
Because everything in this scheme would be tagged, dated, and versioned, it would be trivial to do a search for 'what this document (e.g. website) looked like in 2005', or 'a news article about communism from last Wednesday' or what have you.
Somehow, though, I think this sort of thing is a long ways off. Then again, maybe not.
The first broadband ISP I ever had was Shaw Cable, and back then, there was no such thing as 'broadband routers' - heck, we couldn't even justify buying a switch, so we just used a 10baseT hub (ew).
Imagine my surprise when I found out that our networked Brother printer, which we had only used over Appletalk-over-Ethernet, had had a public IP address for a year. Fortunately, it seems that the printer designers had (for whatever reason) prevented printing/access from non-local subnets, limiting the number of people with access to it to somewhere around 64 or 128 (we weren't part of a full class C, for sensible reasons).
Oddly enough, the ISP wanted you to pay for extra IPs - but didn't require it. Honour system ftw.
Re:Boost epitomizes everything that is wrong with
on
Boost 1.36 Released
·
· Score: 1
I've been saying this about my laptop for years, but I guess now it's time to say it about my phone as well.
The phone I use is small, sleek, looks and works great, and does everythin I need it to. It makes phone calls, does SMS messaging great, and I can sync it with my laptop so all my contacts are updated, always. It also has the nice benefit of having a unix core, dpkg, apt, and a slew of unix utilities. It has a terminal with SSH and telnet, I can mount it as a volume over the network, and it plays music too. Even making ringtones for it is as simple as encoding them as AAC.
So they have Debian on a phone. Great. But just like Debian on desktops, I have to ask myself why anyone but RF geeks would ever care.
My phone, like my computers, are for getting things done. Call me when this thing is useful and usable.
Depends on why they're expensive. On one hand, they might just be a label, but on the other, they might be well-engineered shoes that last longer (my $35 shoes start to wear out after about 6 months of wear), that fit better, that are more comfortable, provide more support, handle the elements better, and so on.
For women's shoes, add a stronger heel, better variety, better style, better fit, and so on.
I think Apple should be commended for turning slaves into workers!
Re:Truly, medical geeks are the alpha geeks.
on
The DIY Dialysis Machine
·
· Score: 3, Informative
Nah, you just need to make sure you have a fresh backup of the baby in case it doesn't work. Then you refine your design and try again. This is why checking your baby into version control is always a good idea, ESPECIALLY after first being released into the wild.
Well obviously the airlines could save a ton of money by making sure their tires are properly pressurized as well! I mean, imagine saving 3% of what they use!
Hate to break it to you, but Tim Hortons is possibly the LEAST recent company to do this. Second Cup, Starbucks, EB Games, and dozens of others have been doing this for ages. Reloadable gift cards are a great idea, and most stores will do them now.
Even better is that some of the companies will start deducting money off them after a certain timeframe (e.g. 2 years) so the million cards with $10 on them that got lost or thrown in the trash will eventually be reclaimed by the company and added to the profits.
Slashdot Mirror
The graphs shown in TFA indicated a 22.2x performance increase in 'function call' 37.5x increase in 'global loop', and 20.8x increase in 'empty loop'.
Then, they turn around and show a Sunspider performance boost of 1.8x - which is still awesome, but nowhere near the factor of 'twenty to forty' that is being carelessly bandied about by those who appear to misunderstand what is being represented.
What the PP seems to suggest is 'don't interpret and then JIT the slow parts, JIT everything'. His rationale is that the time wasted interpreting the code in order to figure out what needs optimizing makes up for the time spent optimizing everything.
For example, if your inner loop takes 3 seconds to execute, the JIT compiler will see that it's taken 3 seconds, and optimize it - if it ever runs again. If your code only takes 4 seconds to run, then 75% of your time is spent in the unoptimized inner loop.
Instead, he seems to propose that you optimize everything immediately, and then execute it. If it takes 1 second to optimize and you can shave 2 seconds off your inner loop in this case, you've saved 1 second overall. If your inner loop takes 9 seconds, you save 5 seconds overall. In essence, pre-compiling pays for itself in most cases.
At least, that was what I got out of it, though I'm open to correction.
Well, if the Mozilla folks come up with a MIME-type for compiled Javascript (e.g. text/x-moz-pc-javascript), then they can send that in the 'accept' header when requesting Javascript files, and then the server will know to send the Firefox precompiled version. WebKit could use text/x-wk-pc-javascript, and the server could send that.
Moving to other languages, however, would be tricky since it's unlikely that the (distressingly common) IE6 users could cope, resulting in having to at least write it in Javascript once.
Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.
They don't need your relay. If they're running on your machine, they can fetch their payload and then start sending it out through your local MTA or configured SMTP server. If you can send e-mail, so can they.
Yes, but without access to the system FF folder, that plugin will go in your per-user plugin directory, and will only run for you. So only your passwords will be stolen, and not those of anyone else on the computer.
Given that most computers running Firefox these days are single-user systems, whether running Linux, OS X, or Windows 98.
Then consider Linux systems. Most systems these days are set up with sudo access, as is OS X. All the bug has to do is watch to see when you run sudo yourself, and then bam, it has a (usually) five-minute window to run itself as root and infect the rest of your system.
It can also grab your ~/.ssh/known_hosts and then reach out to those to see which ones accept your private key; install itself there, and, again, watch for sudo access. It's not hard for someone to go from there out to infecting every machine you have access to, and root on every machine you have root on, and potentially every system that every user on that system has access to, and so on, and so on.
Put another way, a local exploit is only local until you connect to the internet.
So we should have the same freedom on phones as we do on computers.. Makes sense, except that that flexibility also has consequences, and I can't wait to see the first version of McAfee Antivirus or Spysweeper for Android.
See XKCD for another view on the whole 'needs protection' issue.
The problem is that the RTT to Mars can be as high as (about) 2600 seconds, and I don't know any server that's going to wait 45 minutes for a reply, or any client that will wait 45 minutes for an answer from the server. Keepalives and your suggestion (what basically amounts to cache seeding or push prefetching) are great, but on top of a protocol like HTTP it doesn't make sense.
Heck, even TCP requires a SYN, ACK/SYN, ACK handshake, which means that even opening a TCP connection could take a little over an hour, plus another 20 minutes to get the data for your reply. Not very sensible, IMHO. A simple HTTP request ('Hey, can I have /index.html?') would take an hour and a half to get a reply. Not very sensible.
Well as Windows 98 didn't have SP2, I'm assuming you mean XP...
My cable provider blocked broadcast packets, so no one in our neighborhood could see anyone else any better than the rest of the world could see you, which was good. Broadband routers only help because they provide firewalling (a NAT necessity); the same could be done on new routers using IPv6; just have the router block incoming connections by default, and allow specific ports using... well, whatever protocol comes up. NAT-PMP seems oddly named for that, but it should work, as should UPnP.
For an anecdote to compliment your complaint about viruses on Windows, a professor at my university once had his computer plugged into the network while installing Windows. It turns out Windows brings up the network during the install process. End result, his computer was infected with blaster before he was even done installing Windows. Pretty sad.
Are you having the *new* 3G issue? Because the one thing that seems (anecdotally) to be in common for all those affected that I've heard from is an old SIM card (i.e. not the one that came in the box).
People who have the 'I can't get on the 3G network' issue have reported their problems go away when switching to the new SIM. Maybe that's worth trying?
That strikes me as what we in the industry call 'a recipe for disaster'. So how long until we see the first security hole that lets the payload replace the dialler and home screen (and maybe the contacts app) with apps that steal all your shit?
You can natively compare two v4 addresses by using a == b (which will translate into a single assembly instruction). You cannot do that on a 129 bit data item. Your choices are - memcmp, or defined operation (compare first 4 bytes, then next 4 bytes, then next, then next :) ). This is inefficient, prone to error and makes code less maintainable.
Well this might be overkill, but most SIMD units I've seen or dealt with can handle up to 128 bits of data at once - meaning that a simple vectorized function can compare an IPv6 address in a single instruction, so...
In regards to NAT, you seem to suggest that NAT is a natural, organic evolution from IPv4. I would argue that NAT is actually more like a disease - perfectly natural, and entirely undesired. NAT seems to me like chemotherapy is to cancer, actually. We have a problem, and we have a solution - and the solution is, in some cases, worse than the disease. So instead of just having cancer, we now have cancer and radiation sickness. Where the analogy fails is that things aren't going to get better - they'll just keep getting worse. All the radiation therapy is doing is making the pain last longer. IPv6 is the surgery that can excise the tumor entirely, and prevent the pain that we're going through from being necessary at all.
Some things are organic, and some things are artificial. Sometimes, you have to understand that the natural will need to be replaced by the artificial, because the natural is failing, and it's going to take the host with it.
Also, any trolls pulling out the "yuo cant has teh firawalls withouts teh NAT!!!11" crap can please not respond to this as packet filtering does not in any way require NAT. (Not directed at parent post, just tired of trolls and ignorant fools always using that argument).
Well said, a point most people tend to miss when whining about IPv6. If you don't want people getting into your network - well, then say so! It's phenomenally trivial to set up a firewalling rule saying 'No inbound connections are allowed to this address range'. Using VLANs, you could easily subdivide your network, such that any systems you want accessible are on one subnet on one VLAN, and any hosts you don't are on another subnet on another VLAN.
Some people argue that 'Oh, now people outside of my network know that a certain host is the one connecting!' Well, yes, that's true. However, all they know is an address in an address range. They don't actually know anything more than 'A host from this company is connecting', which is what they know now. Them being able to trace individual hosts can be a huge benefit for network admins, because now if someone is getting a lot of traffic from my office, I know exactly where to look without having to check the switch's logs (especially since the switch for our office is managed by someone else).
Do you want outside organisations to find out that the person accessing their webserver is terrance.phillips.accounting.office.internal.company.com ? Well no, of course not - so don't use descriptive revDNS. Workstation-v1104.company.com would work just as well for all purposes, but not expose information to the outside world.
So now we have a system that is as secure as NAT is, as 'private' as NAT is for all intents and purposes, and which can provide even more security up the pipe because the remote host can say 'Hey, you're not from user2023's IP address, so I'm not going to accept your session cookie'.
Oh, and this is anecdotal, but I've found in the past that connecting through a tunnel broker, and then connecting via IPv6 to an IRC server through that tunnel, consistently had less latency than connecting to the same server over IPv4 from the same host (obviously not through the tunnel). Take THAT, overhead haters!
I asked my favourite colocation/networking company, Peer 1 Networks, what their stance was on IPv6. The answer I got back (from their best salesperson) was that they were taking a 'wait and see' attitude. They had no intention of being first, being innovative, or for that matter, doing anything until they saw what other people were doing. There's no money in it, so why bother? IPv6 doesn't get you anything but additional infrastructure that a lot of people these days don't yet fully understand.
I was disappointed, but I don't blame them. It would be great if they did, but honestly, while the tech geek in me wants it, the pragmatist knows that it's not really that useful... At least, not yet.
Still, I pointed out to her that when it IS useful, it would be nice to be there already. She agreed on that, at least in principle.
How about authenticated web apps? IPv6 secures traffic from the user to the cloud. That's something Apple has reason to push with MobileMe: "look at us, we have IPv6 security."
Put another way - 'Look at us, all of your traffic to us goes through some third-party router, and may well be getting sniffed on the way. If a hacker gets them, they win!'
I know that's not true if SSL is used (and MobileMe does use HTTPS for push updates, somehow), but the average user doesn't know that.
Mexican ISPs already NAT a large portion of their subscribers. End result? When someone does something bad (e.g. is being an asshat on IRC, a problem for me back when I was an IRC server admin), you can't narrow down to a specific person.
In my IRC example, banning one IP address would kick off up to a hundred users - pretty insane, considering our net only had a 2400 user record, and half of them were from Mexico. Suddenly, I have 99 pissed-off users, and one asshat who just hops on a proxy instead.
(Of course, since all of these users were teenagers, in the same neighbourhood of the same city and went to the same school, the easiest solution discovered by those of us dealing with Mexican asshats was to tell everyone who it was that had gotten them banned, and reassure them that after the ban expires (usually an hour to start), they won't get banned again unless the asshat acts up again. I'd imagine I caused a lot of threats, angry IM chats, and possibly savage beatings.)
But... do you tie it to the roof then, like with a small truck? I'm confused. I was going to buy a sofa from Ikea's website, and I need to know how to get it home. If I can't dump it in the back of the intertruck, what are my other options?
I've been thinking about this sort of thing for ages, mostly in conjunction with ponderances on things like interplanetary news.
Between Earth and Mars, you can't FTP - the RTT is so long that the protocol-specified maximum timeout expires before a response can be returned to you. Obviously loading up a web page would be a senseless waste of time. We would need a way of transporting or requesting information in batches in order to effectively communicate things like news between planets.
In my mind, while at university, I envisioned a system consisting of 'packages', which contained some data or subset of data. It could be an entire website (which, for many companies, is merely a brochure, menu, etc. anyway), part of a website (an updated to a company's product information pages, for when e.g. Apple ships a new iMac), or even a single file - a press release, news clip, etc.
Each parcel of information would belong somewhere in a heirarchy. You could start with 'Apple' and grab their default content (say, most of what's on their website at first glance), and then delve deeper into areas like 'support', 'developer info', and so on. Those packages, while not necessarily retrieved by default, could be requested, and would slot into the heirarchy. Without them, you see that they're there and what kind of content is available; you can then request the content be updated, and when the 'package' arrives, you suddenly have access to that content as well.
Likewise, you could start issuing specific identification that computers could use to narrow down who you're looking for. Instead of www.apple.com, you could just do a search for 'Apple Computers' or 'Apple, Inc', and you would be able to find relevant information from (and about) the company. Because we can now uniquely identify business electronically, it's easy for someone writing a news article to 'tag' the article as being about Apple, Inc., and your client can do any associations you might want - stock updates, press releases (especially relevant press releases to the story), and so on, and whatever isn't local can be updated.
Obviously, this would require two things; firstly, a complete overhaul in the way the internet works; secondly, local (possibly hierarchical) caches wherever relevant, so that information doesn't need to be transmitted multiple times. Also, the caches can pre-fetch or be pre-seeded content ahead of time, so that (for example) major/popular news sites could send updates to their content in batches every hour/day/etc.
Because everything in this scheme would be tagged, dated, and versioned, it would be trivial to do a search for 'what this document (e.g. website) looked like in 2005', or 'a news article about communism from last Wednesday' or what have you.
Somehow, though, I think this sort of thing is a long ways off. Then again, maybe not.
The first broadband ISP I ever had was Shaw Cable, and back then, there was no such thing as 'broadband routers' - heck, we couldn't even justify buying a switch, so we just used a 10baseT hub (ew).
Imagine my surprise when I found out that our networked Brother printer, which we had only used over Appletalk-over-Ethernet, had had a public IP address for a year. Fortunately, it seems that the printer designers had (for whatever reason) prevented printing/access from non-local subnets, limiting the number of people with access to it to somewhere around 64 or 128 (we weren't part of a full class C, for sensible reasons).
Oddly enough, the ISP wanted you to pay for extra IPs - but didn't require it. Honour system ftw.
I use DJGPP in DOS, you insensetive clod!
I've been saying this about my laptop for years, but I guess now it's time to say it about my phone as well.
The phone I use is small, sleek, looks and works great, and does everythin I need it to. It makes phone calls, does SMS messaging great, and I can sync it with my laptop so all my contacts are updated, always. It also has the nice benefit of having a unix core, dpkg, apt, and a slew of unix utilities. It has a terminal with SSH and telnet, I can mount it as a volume over the network, and it plays music too. Even making ringtones for it is as simple as encoding them as AAC.
So they have Debian on a phone. Great. But just like Debian on desktops, I have to ask myself why anyone but RF geeks would ever care.
My phone, like my computers, are for getting things done. Call me when this thing is useful and usable.
Depends on why they're expensive. On one hand, they might just be a label, but on the other, they might be well-engineered shoes that last longer (my $35 shoes start to wear out after about 6 months of wear), that fit better, that are more comfortable, provide more support, handle the elements better, and so on.
For women's shoes, add a stronger heel, better variety, better style, better fit, and so on.
I think Apple should be commended for turning slaves into workers!
Nah, you just need to make sure you have a fresh backup of the baby in case it doesn't work. Then you refine your design and try again. This is why checking your baby into version control is always a good idea, ESPECIALLY after first being released into the wild.
Well obviously the airlines could save a ton of money by making sure their tires are properly pressurized as well! I mean, imagine saving 3% of what they use!
Hate to break it to you, but Tim Hortons is possibly the LEAST recent company to do this. Second Cup, Starbucks, EB Games, and dozens of others have been doing this for ages. Reloadable gift cards are a great idea, and most stores will do them now.
Even better is that some of the companies will start deducting money off them after a certain timeframe (e.g. 2 years) so the million cards with $10 on them that got lost or thrown in the trash will eventually be reclaimed by the company and added to the profits.
Actual link: http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html