There is something disappointing that punching someone earns 2 people $175 million dollars. Shame we dont have as much enthusiasm for Nobel laureates as we do for sports and the oscars.
You get two Nobel laureates in the ring for a no-holds-barred punch-up, and I'm sure you'll find lots of people willing to pay to watch:D.
Back in the day, software projects used to be killed because of technical limitations. Now they are killed because someone objects to what someone else does in their spare time.
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.
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.
I don't own a cell phone at all. Apparently I am chopped liver, as apparently it is impossible for (nearly) anyone to come up with a 2FA mechanism that doesn't involve a cell phone!
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.
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.
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.
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.
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.
...and they usually add up to a giant, steaming pile of crap.
I worked on a project once that did its best to implement all user requests in its product. By the time I started working on it, there were at least seven different ways to do any basic function, because different users thought it would be great if they each had their own way of doing the same damn thing.
The result? The software was bloated, and damned near impossible to adequately test. The permutations possible to do the exact same task were staggering. This resulted in a lot of weird bugs that weren't found during testing. It made the software brittle, and in the end the same users that wanted all these different ways of doing the same task (multiplied by a few dozen different tasks I might add) weren't happy with the resulting complexity. All that stuff that users thought would be simple and a good idea, in combination, sucked.
Sometimes it's a developers job to say no. It can be very difficult to decide when that time is, but projects that never say no are doomed to failure. Sometimes an over-arching vision as to how the product should work needs to win out over every single good idea some random user has.
I sometimes work with physical tools. And there are times when I'm using a wrench, but need to put it down and start using a hammer. I don't think it's unreasonable of the tool manufacturer to reject it when I suggest to them it would be great if they welded a hammer to all of their wrenches so I didn't have to put one tool down to use the other.
The problem with that is: what's your house's IP address? Thanks to DHCP, no one knows. It can change at any time. So you'd have to use some kind of dynamic DNS service to get around that, and now you're talking about it being too difficult for the average idiot^Wuser to set up and use.
Or you need IPv6. The way the devices would have a real address, and your phone/mobile device could easily interrogate and store the addresses of every device on your local network using ZeroConf. As the resulting addresses would be fully routable on the public internet (assuming your home gateway is firewall setup to passthrough to those addresses on whatever port they use for command and control, which can be done automatically via NAT-PMP or UPNP). You wouldn't even need a server.
Of course, this is a very simplified view -- you'd need security beyond just the home firewall, of course -- the command and control should be 100% encrypted via a per-device key to keep out hackers -- but this is really the model IoT devices need to eventually get to. You wouldn't need any sort of centralized cloud service (although this model also wouldn't prevent one for people who wanted, say, remote web access to their devices from having one. It could be run as a third-party service, or even integrated into something like Facebook, for example); just documentation on the communications command and control protocol(s), and it would be easy for end-users to setup. IPv6 will be a very significant enabling technology for IoT to really take off -- once every device can have its own stable, globally routable address, you won't need to worry about centralized cloud services anymore.
What's easier to backup and restore? Hint a virtual machine image.
Run your tooling inside a Docker container instead. Processes run as local processes without the overhead of virtualization, and the container images can be backed up by pushing them to a repository in a single command. On top of that, Docker container images are way smaller than comparable VM images, as they don't need to store an entire OS as part of the image. In fact, as Docker images are created in layers, two images that share the same base OS layers don't need to store that base OS image layer twice -- in effect, your images are just the diffs from whatever image they are generated from. Way smaller, easier, and faster to backup than a giant VM image.
The absolute best environment? Sitting on my couch, in my pyjamas, with easy access to my refrigerator and tunes.
However, if I catch one of your developers on my couch wearing my pyjamas and helping themselves to my 'fridge while listening to my tunes, there's going to be trouble.
Ultimately, as a developer my preference is to a) have the entire power of the system in my hands, b) not be tied down by local system restrictions, and c) not being tied to specific developer tools, especially an IDE.
Breaking those down:
Entire power of the system: I require my own system that doesn't share any resources with anyone else. It has to be a real desktop or laptop. No thin client of any sort. If I'm out in the woods and away from any form of networking and need to build the product (or some subset), I should be able to do so. If the product relies on or is expected to be used in any sort of cloud technologies, then the ability to generate and use cloud instances is certainly a must, however they should be available alongside and via a real machine, and not be the sole development environment.
Not be tied down by local system restrictions: if IT wants to provide a system so tied down that my local user doesn't have sufficient privileges to install device drivers, tools, or anything else I may need to work, you need to verbally smack them around. That may work for Sales and Marketing, but your most technical people need to have full access to their systems.
Not being tied to specific developer tools: All of the most pain-in-the-butt projects I've ever worked on are those that rely on a specific IDE to build. And this has always wound up being a bad idea. Projects should be buildable without any sort of IDE whatsoever. Use Gradle or Maven or Ant or a Makefile to build your projects. Pretty much every modern IDE can work with these systems. Your developers can pick and choose what IDE and tools they want to use this way -- they should just be able to just 'git clone' or 'svn checkout' and build from the command line. This also tends to mean that your Continuous Integration system will build the product in exactly the same way as developer systems -- which is a good thing. Anytime I've joined a project that is so highly tied to a specific IDE, the instructions and time needed to on-board new developers is always way too high (I've seen documents with over 20 pages just on how to setup your IDE properly to build a specific project! I've also seen bugs in the code that wound up being due to differences in the way code was built in the IDE vs. how it was built on the nightly build server). Decouple how the code is built from what tools are used to write the code whenever and wherever possible, and then I'll pick the local tools that work best for me to write that code.
TL;DR version: give me a lot of computing power I can carry around with me, don't tie me down to specific coding tools, and then get out of my way. And keep your developers off my couch, and out of my pyjamas and 'fridge.
God forbid your daughter consumes paid content without you having to pay a dime for it, paps, while people already paid over Patreon say things you disagree with "for free".
My daughter has zero buying power. She doesn't understand the ads. And what's worse, the ads that typically come up aren't even close to age appropriate. This isn't a case of Youtube showing her ads for toys she might ask me for -- they're ads for inappropriate things. They will never generate a sale for the advertiser.
Yet, at the same time, groups that Google (not I) determines to be disagreeable will now have an ad-free experience. I'd actually rather that if they insist on showing my daughter an ad for haemorrhoid cream when she wants to watch "Wheels on the Bus", that people watching "disagreeable" videos should have to watch them too.
I'm not complaining about the need for ads; it's that they're effectively going to be exempting you from seeing advertising if you're watching terrorist propaganda, or racist rants, or two girls one cup, or whatever else gets deemed "inappropriate", while at the same time happily showing my 6 year old daughter ads for erectile dysfunction medication when see wants to watch "Wheels on the Bus".
If you had google music or youtube red there wouldn't be ads.
Which would be fine if Youtube Red were available in my country. But it isn't. I'm not sure about Google Music -- it's not a service I have need of anyway.
I do agree that it's messed up. Even the dumbest Americans should be capable of realizing that running ads during a youtube video doesn't equal approving of the content. But we didn't have so many idiots, we wouldn't have the problems we do today.
Believe it or not, advertisers are human beings too. And while they don't want to be seen endorsing or being associated with the types of videos the article discusses (bad optics), at the same time they also don't want the people who make these videos to benefit from their advertising dollars either, just as (I presume) you or I wouldn't donate money to a Jihadist group, or NAMBLA, or the KKK, etc. So I'm happy to give the advertisers some slack on this -- most decent people, advertisers or not, don't want to see their money going to such groups, even if everyone else were fine with it.
American companies swiftly followed, even after Google promised Tuesday to work harder to block ads on "hateful, offensive and derogatory" videos.
So let me get this straight -- racists, misogynists, and terrorists are going to benefit from an ad-free experience, and yet my 6 year old daughter has to put up with ads for mortgages and makeup and other adult stuff when she wants to watch kids videos? WTF did we ever do to you Google that dirtbags get an out from Youtube ads, but the rest of us have to suffer?
Slashdot Mirror
There is something disappointing that punching someone earns 2 people $175 million dollars. Shame we dont have as much enthusiasm for Nobel laureates as we do for sports and the oscars.
You get two Nobel laureates in the ring for a no-holds-barred punch-up, and I'm sure you'll find lots of people willing to pay to watch :D.
Yaz
Back in the day, software projects used to be killed because of technical limitations. Now they are killed because someone objects to what someone else does in their spare time.
So you're saying you want to bring back ReiserFS?
Yaz
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.
Yaz
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.
Yaz
+5 here we come!
So what am I? Chopped liver?
I don't own a cell phone at all. Apparently I am chopped liver, as apparently it is impossible for (nearly) anyone to come up with a 2FA mechanism that doesn't involve a cell phone!
Yaz
Who *WANTS* it?
I would, if it meant we could port SOM and the Workplace Shell to Linux.
Yaz
7. Don't listen to anybody that has been paid by someone else to get you to do/eat/take something.
How do we know you weren't paid to tell us this?
Comcast employees admit they cut the wires, but they claim that they thought the wires were abandoned.
Which is why you typically test for active signal on a line before you cut it.
Yaz
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.
Yaz
So... if I do get this kind of malware, it'll install less crap on my system? Seems like a win to me.
Hey, why don't we just pre-install the malware in that case? That way it won't have to install any crap on your system -- it will already be there!
Yaz
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.
Yaz
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.
Yaz
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.
This book would have changed my world had I read it when I was four. But now that I'm 44, not so much.
Yaz
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.
Yaz
...and they usually add up to a giant, steaming pile of crap.
I worked on a project once that did its best to implement all user requests in its product. By the time I started working on it, there were at least seven different ways to do any basic function, because different users thought it would be great if they each had their own way of doing the same damn thing.
The result? The software was bloated, and damned near impossible to adequately test. The permutations possible to do the exact same task were staggering. This resulted in a lot of weird bugs that weren't found during testing. It made the software brittle, and in the end the same users that wanted all these different ways of doing the same task (multiplied by a few dozen different tasks I might add) weren't happy with the resulting complexity. All that stuff that users thought would be simple and a good idea, in combination, sucked.
Sometimes it's a developers job to say no. It can be very difficult to decide when that time is, but projects that never say no are doomed to failure. Sometimes an over-arching vision as to how the product should work needs to win out over every single good idea some random user has.
I sometimes work with physical tools. And there are times when I'm using a wrench, but need to put it down and start using a hammer. I don't think it's unreasonable of the tool manufacturer to reject it when I suggest to them it would be great if they welded a hammer to all of their wrenches so I didn't have to put one tool down to use the other.
Yaz
I'd love to see them make an emulator or compilation for Intel OS X.
Seems you got your wish.
Yaz
The problem with that is: what's your house's IP address? Thanks to DHCP, no one knows. It can change at any time. So you'd have to use some kind of dynamic DNS service to get around that, and now you're talking about it being too difficult for the average idiot^Wuser to set up and use.
Or you need IPv6. The way the devices would have a real address, and your phone/mobile device could easily interrogate and store the addresses of every device on your local network using ZeroConf. As the resulting addresses would be fully routable on the public internet (assuming your home gateway is firewall setup to passthrough to those addresses on whatever port they use for command and control, which can be done automatically via NAT-PMP or UPNP). You wouldn't even need a server.
Of course, this is a very simplified view -- you'd need security beyond just the home firewall, of course -- the command and control should be 100% encrypted via a per-device key to keep out hackers -- but this is really the model IoT devices need to eventually get to. You wouldn't need any sort of centralized cloud service (although this model also wouldn't prevent one for people who wanted, say, remote web access to their devices from having one. It could be run as a third-party service, or even integrated into something like Facebook, for example); just documentation on the communications command and control protocol(s), and it would be easy for end-users to setup. IPv6 will be a very significant enabling technology for IoT to really take off -- once every device can have its own stable, globally routable address, you won't need to worry about centralized cloud services anymore.
Yaz
What's easier to backup and restore? Hint a virtual machine image.
Run your tooling inside a Docker container instead. Processes run as local processes without the overhead of virtualization, and the container images can be backed up by pushing them to a repository in a single command. On top of that, Docker container images are way smaller than comparable VM images, as they don't need to store an entire OS as part of the image. In fact, as Docker images are created in layers, two images that share the same base OS layers don't need to store that base OS image layer twice -- in effect, your images are just the diffs from whatever image they are generated from. Way smaller, easier, and faster to backup than a giant VM image.
Yaz
The absolute best environment? Sitting on my couch, in my pyjamas, with easy access to my refrigerator and tunes.
However, if I catch one of your developers on my couch wearing my pyjamas and helping themselves to my 'fridge while listening to my tunes, there's going to be trouble.
Ultimately, as a developer my preference is to a) have the entire power of the system in my hands, b) not be tied down by local system restrictions, and c) not being tied to specific developer tools, especially an IDE.
Breaking those down:
TL;DR version: give me a lot of computing power I can carry around with me, don't tie me down to specific coding tools, and then get out of my way. And keep your developers off my couch, and out of my pyjamas and 'fridge.
Yaz
God forbid your daughter consumes paid content without you having to pay a dime for it, paps, while people already paid over Patreon say things you disagree with "for free".
My daughter has zero buying power. She doesn't understand the ads. And what's worse, the ads that typically come up aren't even close to age appropriate. This isn't a case of Youtube showing her ads for toys she might ask me for -- they're ads for inappropriate things. They will never generate a sale for the advertiser.
Yet, at the same time, groups that Google (not I) determines to be disagreeable will now have an ad-free experience. I'd actually rather that if they insist on showing my daughter an ad for haemorrhoid cream when she wants to watch "Wheels on the Bus", that people watching "disagreeable" videos should have to watch them too.
Yaz
Daddy? What's erectile dysfunction and should we ask the perdiatrician if cialis is right for me?
Daddy has no idea what that is, or what it's for ;).
If it were up to me, you'd be modded +5 Funny.
Yaz
You use bandwidth without paying for it.
I'm not complaining about the need for ads; it's that they're effectively going to be exempting you from seeing advertising if you're watching terrorist propaganda, or racist rants, or two girls one cup, or whatever else gets deemed "inappropriate", while at the same time happily showing my 6 year old daughter ads for erectile dysfunction medication when see wants to watch "Wheels on the Bus".
If you had google music or youtube red there wouldn't be ads.
Which would be fine if Youtube Red were available in my country. But it isn't. I'm not sure about Google Music -- it's not a service I have need of anyway.
I do agree that it's messed up. Even the dumbest Americans should be capable of realizing that running ads during a youtube video doesn't equal approving of the content. But we didn't have so many idiots, we wouldn't have the problems we do today.
Believe it or not, advertisers are human beings too. And while they don't want to be seen endorsing or being associated with the types of videos the article discusses (bad optics), at the same time they also don't want the people who make these videos to benefit from their advertising dollars either, just as (I presume) you or I wouldn't donate money to a Jihadist group, or NAMBLA, or the KKK, etc. So I'm happy to give the advertisers some slack on this -- most decent people, advertisers or not, don't want to see their money going to such groups, even if everyone else were fine with it.
Yaz
So let me get this straight -- racists, misogynists, and terrorists are going to benefit from an ad-free experience, and yet my 6 year old daughter has to put up with ads for mortgages and makeup and other adult stuff when she wants to watch kids videos? WTF did we ever do to you Google that dirtbags get an out from Youtube ads, but the rest of us have to suffer?
Yaz