Would you rather profit $1 each off a million people and have to deal with all their petty support issues?
Or profit $100 off 10,000?
That's fine, until you consider that a portion of those 990,000 possible customers you decided not to pursue would also have bought apps, subscriptions and services. Of course your reasoning still makes sense, but the walled-garden-model, with its hefty fees for any sale, tends to move the break-even point around.
Wrong CPU, nothing to do with 4/586s. From TFA itself:
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users.
Leaving aside the technicalities of what chrisvdb could do with his app, I can attest that the review process is hell: you are usually talking (o writing to) to some moron who doesn't understand the implications of what they're asking, especially when you're dealing with corner cases. I had the same problem one year ago: my app is basically used in a room setting together with other apps of its kind to perform some activities (there are notifications exchanged among the apps). The Apple representative kept asking for a demo account, and I tried to explain to him in every possible way that there was no problem in supplying the account, but it would have been perfectly useless if he was the only user, and that they all had to be online at the same time. Well, since the app had to be published, I had to write a "demo mode" for the guy (several days of work plus, as a hurry-induced bonus, several regressions in the code, that I had to fix later): whenever an account belonging to a special group was used, the app would start acting on its own, faking all its actions. Of course this was not a real-word test of anything, but Apple's QA process was accomplished.
It works for a gym because as long as it is open and the staff is paid, the marginal cost for every customer who uses your gym is almost non-existent: whether they use it every day or once every six months, it basically makes no difference. You probably have to wash more towels or clean more frequently, but this is small change and easily absorbed. And maintenance and replacement of the exercise machines is not so frequent that it can't be planned and incorporated into the pricing structure.
On the contrary, every customer that gets a ticket from MoviePass is a net loss for them.
At that time I was working in a shop that only sold Apple computers, and I had been working there for a few years. The first iMac, from a technical standpoint, wasn't really something to write home about: slow, prone to over-heating, no SCSI, floppy, ADB or serial when many people still used them (so you had to throw in the garbage all your old peripherals); the USB subsystem was lacking reliable drivers, so in the first months you had to choose between a floppy drive and a printer. Yes, it was repairable, but in 1998 that was still a given (and, anyway, putting an iMac back together after disassembling required some serious swearing, the damn thing had its insides so tightly packed, it wouldn't stick together if you routed the spaeaker cable the wrong way).
But its greatest achievement was putting Macintosh computers back on the map. The iMac wasn't a champion, but it was pretty and shiny. When Apple, afew years later, presented later the "flower power" and "dalmatians" versions, they knew perfectly well that they wouldn't sell, but they were just meant to generate enough buzz in the press. And that was the iMac did: before its time, Macintosh computers were either (very) expensive and confined to DTP/graphic/music professionals, or (not so) cheap, outdated and unreliable. The iMac changed all that and prepared the terrain for the advent of OSX and, ultimately, of the iPhone. People instantly loved it, and there was nothing you could say about screen resolutions, a substandard graphic card (ATI Rage II/II Pro? Really?) or anything else that could make them change your mind. And it sat very well on your desk, no more square beige boxes or ugly CRT monitors with lots of cables: the iMac proved that computers, other than being a useful tool, could be a fashion statement and an extension of your (purported, at least) personality.
If you have to take along a 300kW gasoline-powered turbine and a copy machine-sized unit, isn't it easier to just throw this stuff in the path of the car you want to stop?
Think about it... If you were searched by border patrol in a fscked up country and you were taking pictures of things that "no one is supposed to know about". What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.
There's no win-win scenario here, a lot would be riding on the actual situation on the ground, and on the stakes at risk. This is why having the possibility of encryption would be a good thing.
The reason why we're not having it even on high-end SLRs (after the Nikon encryption fiasco in 2011 and the half-assed attempts years ago by Canon to implement it, along with digital signature) is completely clear: while professionals and their endorsement help to sell a camera (and a brand), they're only a tiny fraction of the whole market. And while you can sell "hyper-blazing fast autofocus with a megazillion focus points" to anyone with a enough cash to spare, even if that US$ 4000 camera is used for kids birthdays and picnics, encryption is still going to be a feature that only a small percentage of users will ever use. Add to that the fact: 1) it is not so easy to handle encryption reliably when you have non technical (in the IT-sense) users 2) you will have to keep restrictions to a minimum because encryption should not get in the way of doing one's job 3) cameras are not really designed for easy and quick software updates when (not if) a vulnerability is discovered, and, well, you get the picture (sorry for the pun, I couldn't resist).
Paper is pretty secure here, where most anyone and especially members of all parties, can watch the whole process.
Yes, that's pretty much it. There are scams you can use with paper ballots, but they're harder to get it to scale
That's important, but there's more: with paper ballots, literally anyone, on a small scale, even without any formal education at all, can understand the principles involved and monitor the process, before or afterwards. With electronic voting, you need people with experience (and very possibly degrees) in cryptography and security. Not only this severely restricts the number of people who are able to assess if the process is rigged, but also it makes the process "less democratic", given that the greater part of the population, in practice, is hindered from exercising their right to check that the election process was really fair.
You're not really supposed to "unlock" an iPhoneX. The way FaceID is supposed to work, you pick it up from somewhere and when you instinctively look at the screen, it performs its magic and it's ready, no need to put the right finger on a sensor in the right way, or click on anything. After some time, you're probably going to forget it's actually authenticating you. Unfortunately, while in theory quite convenient, this has several drawbacks in terms of security and usability; it's not really a step forward from fingerprint authentication (that in turn has its problems), more of a step aside.
So, you take a brand new technology, that is expected to have some rough edges, you test it in the worst possibile environment (noisy and crowded streets with a lot of traffic) and you're surprised of the result? Moreover you used: a) a language (Chinese) that due to its nature is really difficult to recognize efficiently. b) a language (Italian) as spoken by Italian-Americans of several generations, so with a strong accent, regional influences and maybe a few grammatical errors in the mix (I'm Italian-Italian myself so I know what could be expected).
I'm not saying that Google buds are great, maybe they really do suck, but this sounds more like a rant than a well-informed test. Then, of course, can debate whether Apple's approach (bringing a technology on the market when it's mature, instead of jumping first on the bandwagon) works better or it's just a strategy to make your competitors fail in a series of inevitable pitfalls.
Not necessarily true: if you want the system to be able to mount a volume without user intervention (or boot from it), it must know the whole password, a hasj is not enough for decryption. Of course the password should be properly encrypted with a not easily accessible system-level key.
There is a reason cruise ships do not make an ideal target for international or domestic terrorists: while you can bring down an airplane with a theoretical tablet-sized bomb, the results on a ocean cruiser would be much less devastating, you could "score" a few deaths when people are in line at the cafeteria, but then you might as well avoid boarding a ship and attack a crowded bar instead.
Of course you could try to pull an Achille Lauro-style operation, but that is a different beast than smuggling a bomb.
No, and BTW they can possibly seize your server, but we are not talking about perfect anonymity, just improving privacy, and a "home-made" VPN goes a long(er) way towards that.
Not really: Huawei phones are Chinese-made, but they're not your typical super-cheap crap that doesn't work half of the time (and believe me, I speak from experience). They have good build quality, and you will find they are affordable, but nonetheless they're fast and reliable.
In the era of DOS applications, F3 was the nearly universal key for exiting the program, and returning to the DOS prompt.
It was actually a holdover from the mainframe/3270 days, when F3 (PF3 in IBM parlance) was universally used to exit a running program.
Would you rather profit $1 each off a million people and have to deal with all their petty support issues?
Or profit $100 off 10,000?
That's fine, until you consider that a portion of those 990,000 possible customers you decided not to pursue would also have bought apps, subscriptions and services. Of course your reasoning still makes sense, but the walled-garden-model, with its hefty fees for any sale, tends to move the break-even point around.
This double post is proof that, at least on Slahdot, lightning may actually strike twice, and usually does.
Wrong CPU, nothing to do with 4/586s. From TFA itself:
The Linux x32 ABI as a reminder requires x86_64 processors and is engineered to support the modern x86_64 features but with using 32-bit pointers rather than 64-bit pointers. The x32 ABI allows for making use of the additional registers and other features of x86_64 but with just 32-bit pointers in order to provide faster performance when 64-bit pointers are unnecessary.
While the x32 support was plumbed through the Linux landscape, it really hasn't been used much. Kernel developers are now discussing the future of the x32 ABI due to the maintenance cost involved in still supporting this code but with minimal users.
Leaving aside the technicalities of what chrisvdb could do with his app, I can attest that the review process is hell: you are usually talking (o writing to) to some moron who doesn't understand the implications of what they're asking, especially when you're dealing with corner cases. I had the same problem one year ago: my app is basically used in a room setting together with other apps of its kind to perform some activities (there are notifications exchanged among the apps). The Apple representative kept asking for a demo account, and I tried to explain to him in every possible way that there was no problem in supplying the account, but it would have been perfectly useless if he was the only user, and that they all had to be online at the same time. Well, since the app had to be published, I had to write a "demo mode" for the guy (several days of work plus, as a hurry-induced bonus, several regressions in the code, that I had to fix later): whenever an account belonging to a special group was used, the app would start acting on its own, faking all its actions. Of course this was not a real-word test of anything, but Apple's QA process was accomplished.
It works for a gym because as long as it is open and the staff is paid, the marginal cost for every customer who uses your gym is almost non-existent: whether they use it every day or once every six months, it basically makes no difference. You probably have to wash more towels or clean more frequently, but this is small change and easily absorbed. And maintenance and replacement of the exercise machines is not so frequent that it can't be planned and incorporated into the pricing structure.
On the contrary, every customer that gets a ticket from MoviePass is a net loss for them.
At that time I was working in a shop that only sold Apple computers, and I had been working there for a few years. The first iMac, from a technical standpoint, wasn't really something to write home about: slow, prone to over-heating, no SCSI, floppy, ADB or serial when many people still used them (so you had to throw in the garbage all your old peripherals); the USB subsystem was lacking reliable drivers, so in the first months you had to choose between a floppy drive and a printer. Yes, it was repairable, but in 1998 that was still a given (and, anyway, putting an iMac back together after disassembling required some serious swearing, the damn thing had its insides so tightly packed, it wouldn't stick together if you routed the spaeaker cable the wrong way).
But its greatest achievement was putting Macintosh computers back on the map. The iMac wasn't a champion, but it was pretty and shiny. When Apple, afew years later, presented later the "flower power" and "dalmatians" versions, they knew perfectly well that they wouldn't sell, but they were just meant to generate enough buzz in the press. And that was the iMac did: before its time, Macintosh computers were either (very) expensive and confined to DTP/graphic/music professionals, or (not so) cheap, outdated and unreliable. The iMac changed all that and prepared the terrain for the advent of OSX and, ultimately, of the iPhone. People instantly loved it, and there was nothing you could say about screen resolutions, a substandard graphic card (ATI Rage II/II Pro? Really?) or anything else that could make them change your mind. And it sat very well on your desk, no more square beige boxes or ugly CRT monitors with lots of cables: the iMac proved that computers, other than being a useful tool, could be a fashion statement and an extension of your (purported, at least) personality.
If you have to take along a 300kW gasoline-powered turbine and a copy machine-sized unit, isn't it easier to just throw this stuff in the path of the car you want to stop?
Not likely, since apparently the last time it needed to be rebooted was 20 years ago.
Think about it... If you were searched by border patrol in a fscked up country and you were taking pictures of things that "no one is supposed to know about". What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.
There's no win-win scenario here, a lot would be riding on the actual situation on the ground, and on the stakes at risk. This is why having the possibility of encryption would be a good thing.
The reason why we're not having it even on high-end SLRs (after the Nikon encryption fiasco in 2011 and the half-assed attempts years ago by Canon to implement it, along with digital signature) is completely clear: while professionals and their endorsement help to sell a camera (and a brand), they're only a tiny fraction of the whole market. And while you can sell "hyper-blazing fast autofocus with a megazillion focus points" to anyone with a enough cash to spare, even if that US$ 4000 camera is used for kids birthdays and picnics, encryption is still going to be a feature that only a small percentage of users will ever use. Add to that the fact: 1) it is not so easy to handle encryption reliably when you have non technical (in the IT-sense) users 2) you will have to keep restrictions to a minimum because encryption should not get in the way of doing one's job 3) cameras are not really designed for easy and quick software updates when (not if) a vulnerability is discovered, and, well, you get the picture (sorry for the pun, I couldn't resist).
Paper is pretty secure here, where most anyone and especially members of all parties, can watch the whole process.
Yes, that's pretty much it. There are scams you can use with paper ballots, but they're harder to get it to scale
That's important, but there's more: with paper ballots, literally anyone, on a small scale, even without any formal education at all, can understand the principles involved and monitor the process, before or afterwards. With electronic voting, you need people with experience (and very possibly degrees) in cryptography and security. Not only this severely restricts the number of people who are able to assess if the process is rigged, but also it makes the process "less democratic", given that the greater part of the population, in practice, is hindered from exercising their right to check that the election process was really fair.
Single-payer would bankrupt the country. There will never be enough of anything to satisfy demand completely.
Well, I just can't understand how most of Europe and Canada do it without actually going bankrupt.
I was born, raised and I live in Rome, Italy, and I'm writing this very message from my house in Rome
I can confidently affirm that no such thing as "Romano cheese" exists.
You're not really supposed to "unlock" an iPhoneX. The way FaceID is supposed to work, you pick it up from somewhere and when you instinctively look at the screen, it performs its magic and it's ready, no need to put the right finger on a sensor in the right way, or click on anything. After some time, you're probably going to forget it's actually authenticating you. Unfortunately, while in theory quite convenient, this has several drawbacks in terms of security and usability; it's not really a step forward from fingerprint authentication (that in turn has its problems), more of a step aside.
So, you take a brand new technology, that is expected to have some rough edges, you test it in the worst possibile environment (noisy and crowded streets with a lot of traffic) and you're surprised of the result? Moreover you used: a) a language (Chinese) that due to its nature is really difficult to recognize efficiently. b) a language (Italian) as spoken by Italian-Americans of several generations, so with a strong accent, regional influences and maybe a few grammatical errors in the mix (I'm Italian-Italian myself so I know what could be expected).
I'm not saying that Google buds are great, maybe they really do suck, but this sounds more like a rant than a well-informed test. Then, of course, can debate whether Apple's approach (bringing a technology on the market when it's mature, instead of jumping first on the bandwagon) works better or it's just a strategy to make your competitors fail in a series of inevitable pitfalls.
Not necessarily true: if you want the system to be able to mount a volume without user intervention (or boot from it), it must know the whole password, a hasj is not enough for decryption. Of course the password should be properly encrypted with a not easily accessible system-level key.
There is a reason cruise ships do not make an ideal target for international or domestic terrorists: while you can bring down an airplane with a theoretical tablet-sized bomb, the results on a ocean cruiser would be much less devastating, you could "score" a few deaths when people are in line at the cafeteria, but then you might as well avoid boarding a ship and attack a crowded bar instead.
Of course you could try to pull an Achille Lauro-style operation, but that is a different beast than smuggling a bomb.
It can be upgraded to Windows 10 Pro, for free until Dec. 31st, 2017, or paying US$ 50 after that.
That's already dead:
http://www.teslarati.com/tesla-shuts-down-battery-swap-program-for-superchargers/
No, and BTW they can possibly seize your server, but we are not talking about perfect anonymity, just improving privacy, and a "home-made" VPN goes a long(er) way towards that.
They'll power the thing with Musk's ego and sense of importance, that should provide enough power for the next 100 years.
if (a = b) {
When they meant:
if (a == b) {
Which is the one thing Visual Basic got right IMHO, use := for assignment and == for comparison..
Except it didn't, VB6 and VB.Net use "=" both for comparison and assignment, Pascal and PL/SQL, among others, use the ":=" operator for assignment.
Not really: Huawei phones are Chinese-made, but they're not your typical super-cheap crap that doesn't work half of the time (and believe me, I speak from experience). They have good build quality, and you will find they are affordable, but nonetheless they're fast and reliable.
Do what you want with your GOTOs, but do not bring ALTER back.
In terms of innovation, it still beats rounded corners