Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:100% completely incomptable with modern logisti (Score 1) 322

The idea that you're going to have fleet of trucks that will ONLY get 200 or 300 miles on a charge is LAUGHABLE worthless in any but the most specialized situations.

For long haul, sure. But that's hardly the only type of truck in use on roads and highways today. All of the big courier and postal companies have fleets of trucks used just for commercial pickups and deliveries. These trucks don't run all day long -- they often run a route in the morning delivering packages, and a route in the afternoon picking up packages. They only route starting and ending at their local distribution centre, and spend a good deal of time stopped, and won't put 200 - 300 miles on them in a day. And I'd guess that, in North America, there are over 100 000 such trucks on the roads on any given day. Those trucks aren't in use at night, and so could make economic sense to run in an electric variant.

Local in-town moving trucks would be another possible example that could benefit from an electric fleet. People don't move their houses and apartments at night, and short-haul moves can typically be completed within a day. According to this source, nearly 60% of all personal residential moves in the United States are within the same county. All of these could easily be serviced by an electric vehicle with a 200 - 300 mile range.

I don't think either of these examples is a "specialized" situation (according to the above source, in the year in question there were over 23 million moves within county) -- they're just different from the type of hauling and logistics _you_ have experience with. Tesla's trucks aren't aimed at the type of hauling you're discussing -- but there is still a pretty massive market for smaller regional hauling that Telsa could tap into if they get the economics right.


Comment Re:Wouldn't work in Canada (Score 2) 91

As per the subject, that country would be Canada. And for all its ugly labels, the "no name" brand is pretty much the top selling grocery brand in the country.

When initially launched int he late 70s, the simple black-on-yellow labelling was actually part of the sales pitch -- that you could get quality products for cheaper than the major brand names in part because they don't waste money on fancy packaging. There isn't much in the way of marketing, and they're primarily sold in stores owned by the same parent corporation. So it's basically an in-store brand that has over 2900 products. And for the most part, they both consistently cheaper and are generally high quality.

You can browse many of their products here.. And Wikipedia has some history of the brand here.


Comment Re:Is this my problem? (Score 1) 80

Well... because then you'd have malware. A big part of my point was that malware authors have already been able to include a headless browser if they wanted to, so it doesn't seem like this really changes their ability to have their malware perform click-fraud. It just means that, if you're unfortunate enough to get click-fraud malware, it won't also download their headless browser.

Detection may be more difficult. If Chrome is your browser of choice, then having Chrome processes running on your computer won't be all that unusual. An automated process scanner and/or manually looking at a process list may not show anything out of the ordinary. So while seeing "phantomjs.exe" in your process list may set off some alarm bells, "chrome.exe" won't have the same effect.

As well, something like PhantomJS is rarely up-to-date with the latest web technologies. Even though it's based off WebKit, it's based off an older rendering/JS engine. Malware authors can't aways rely on automated software updates to keep the things up-to-date at the best of times, but Chrome is pretty aggressive at keeping itself updated, and is quite aggressive at staying on top of the latest web standards. Having that available saves the malware authors a lot of time and effort -- effectively the user will keep the core part of their malware up-to-date for them, and they can rely on having the latest and greatest rendering and Javascript engines at their fingertips.

Will that matter much in the real world? It's currently hard to tell. Obviously people who willingly install trojan horse style malware aren't the most savvy of users, so perhaps it doesn't make a lot of difference in terms of number of malware instances deployed. But it might make that malware harder for the average user to easily detect, and it might make malware more effective in terms of being able to keep up with the latest web standards and Javascript features and optimizations. I agree that the article makes this sound more series than it probably will be. Time will tell I suppose.


Comment Re:They just weren't agile enough to survive. (Score 1) 193

So, when they came out with an ARM-based Palm, that ARM ran a 68000 emulator, and their entire operating system ran in the emulator along with all apps. So, it was obvious this company wasn't agile enough to keep up with new technology.

Palm had a pretty tortured history as a company, having gone from Palm Computing to being bought out by US Robotics, which was then bought out by 3Com; the founders left to form Handspring, then Palm was spun-off into its own company again, then that company broke up into PalmSource and palmOne, palmOne became Palm again, and PalmSource was bought out by ACCESS. Palm was then bought out by HP.

I had a contact within Palm back in the mid-late 90s, when I met one of their development managers online in an IBM alphaWorks forum for a library someone wrote that allowed you to read/write to and from the Palm Desktop for Windows storage format in Java, as a way of allowing "synchronization" access for Java applications running on Windows. We thought this silly, so I undertook to implement the full HotSync protocol stack in Java, which became the jSyncManager [sourceforge.net]. At the time I started the effort, the general online consensus was that Java simply wasn't fast enough to do the job, but by the time I released v1.0, the jSyncManager was faster than Windows HotSync at just over twice as fast (this was due to a number of factors, the biggest of which being that the jSyncManager supported 115.2k serial line connections, while HotSync for Windows maxed out at the time at 57.6k, however the jSyncManager had a variety of other optimizations in the sync protocol that helped speed things up). I got no help from Palm -- everything had to be reverse engineered. The manager at Palm was impressed -- but after that he was moved around, my contact was lost, and Palm lost any fledgling interest it had in having a single platform upon which you could sync all your PalmOS devices, on any platform.

(FWIW, more than just a desktop sync solution, you could run the jSyncManager in server mode and task a number of sync listeners on one box that could listen to serial and USB docks, along with modem and later TCP connections. This was popular in a number of large corporations, especially after an IBM employee created a free Lotus Notes sync plug-in. IBM even offered to buy out the rights, but the asking amount was low, and they wanted to bury the software after selling service contracts to some big German insurance company).

It was tough trying to gain or maintain any sort of contacts within Palm at this time -- people seemed to move around, and the near constant shifting of who owned them seemed to take a real toll. My feeling was that there was a big NIH syndrome within the organization, as well as no desire to take any risks whatsoever. They were slow moving and conservative -- they felt they were on top, and that they barely had to do anything to keep their position. They wrote OSs that were never deployed (Cobolt), they took what felt like forever embracing colour screens or even WiFi (and even when they did, they failed to keep up with standards -- my Tungsten C was the last non-WPA device on my network). By the time they eventually decided to pivot, the writing was on the wall, and it was already too late.

I didn't do too badly with the jSyncManager, which was a moderate success. I eventually got a contract to develop some plug-ins for an e-Health initiative using the jSyncManager Server, doing a secure WiFi HotSync of digital e-Health patient records. Unfortunately, by the time that project was nearly ready to launch, the writing was on the wall for Palm, and the project was eventually cancelled.

So my feeling at the time jives with yours. And I agree -- they should have dumped their own kernel and used an Open Source kernel instead. But they didn't have that kind of imagination.


Comment Re:I use two (Score 1) 322

I use Apple for personal email. I have had a mac.com email address since Apple came out with it. Their current server name is "me.com" and Apple does not advertise in this service, as it is a paid-for service. It allows pop3 as well as IMAP.

You are way behind the times on this.

Apple replaced the "me.com" domain with "icloud.com" back in October 2011. They continue to maintain the "mac.com" and "me.com" domain names, but only for those people who were members back when those domain names were in current use. If you sign up for an account with them today, you'll get an "icloud.com" address.

And secondly, an iCloud e-mail account is free, and has been since October 2011 when they got rid of the monthly subscription fees that were previously applied to the .Mac and MobileMe services. Indeed, the only thing you can pay for now is extra storage space -- I believe you get 5GB of free storage space, but can pay a small monthly fee for more.

You are correct about it being advertising-free, and the POP3 and IMAP support.


Comment Re:This is generally, and specifically, incorrect (Score 2) 367

I keep wondering if people in general are thinking (wrongly) that 64bit is faster than 32bit as well.

They're not wrong, it's simply that the answer is nuanced.

Intel and AMD CPUs will run properly compiled and optimized code faster in 64 bit mode than in 32 bit mode simply because there are a ton more general purpose registers available in 64 bit mode that aren't present when running in 32 bit mode. And while "more registers" isn't specifically a property of using a 64-bit processor (you could design an 8-bit processor with hundreds of registers if you wanted), in real world practical terms it does mean that 64-bit on Intel can be faster than 32-bit on the same processor.

As well, you can do 64-bit math faster when running in 64 bit mode. Calculating "5e9/7" in 64-bit mode is one instruction, but in 32 bit mode it can require dozens of instructions to get the same answer (I actually coded an example for compilation in 32 and 64 bit modes, and while the 64 bit compile shows the divide happening on one instruction, I couldn't calculate the total number of instructions required in 32 bit mode as the compiler sent the job to a standard library procedure (___udivdi3), leaving my disassembly just showing a CALL statement to this proc.). Yes, you can argue that many applications don't require doing 64 bit math, but for those that do it's quite a lot faster on a 64-bit system than on a 32 bit system. And that is an inherent property of any 64-bit CPU.

Lastly, we have memory mapped files. 64-bit CPUs, with their massive virtual address space can handle huge memory mapped files extremely efficiently. A 64 bit process can conceptually memory map a 64 exabyte file. A 32 bit process can only memory map a 4 gigabyte file maximum. It's not hard for a large database to exceed 4Gb in size, and being able to map such an entire file to memory at once can be extremely efficient compared to the code you'd need to to easy random access inside a >4Gb database file on a 32-bit processor.

So there are cases where 64 bit CPUs are noticeably faster than a 32-bit CPU. CPU-wise I'm not aware of any instructions which are faster on 32-bit processors than they are on 64-bit processors; the advantages are entirely the other way.

Comment Re:Who buys this crap? (Score 3, Insightful) 109

I inherited a watch from my grandfather after her passed away. He wore it for decades. I'm pretty sure the band isn't original -- it seems much newer than the watch itself.

But get this -- to use it you have to wind it up -- every day! Can you imagine such a thing? This man, and many others like him for decades started their day having to wind their watch, because you couldn't go a couple of days without winding it.

And somehow, perhaps miraculously, his generation won WWII. He himself served in the Canadian Forces, attaining the rank of Sergeant. And yet every day he had to wind his watch.


Slashdot Top Deals

"I say we take off; nuke the site from orbit. It's the only way to be sure." - Corporal Hicks, in "Aliens"