Sounds like the issue is that certs have expiration dates -- which is dumb.
"I trust you today, in 2017 I won't though."
That is just asinine. Either the two sides trust each other or not, the "current date" of the clock on either side should not invalidate that trust.
Great! NOW How is VeriSign supposed to make money, if they can't charge you over and over again every year for the same thing, where only the expiration date and signature block are different? 1/2 8-)
I'm just staring at your comment and blinking, because...wow. Even if I ignore #1&2, #3..."and is typically only an issue for calendaring and scheduling." How about queuing? How about clustering? How about expiration of millions of things (tokens, certs, leases, etc). How about practically everything your computer is doing? Unless you're meaning to say that everything really does boil down to "calendaring" and "scheduling," and you're not just making some Outlook comment. If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.
IT's not an issue for queueing; you enqueue things "now". So, for example, you could modify IBM's MQSeries, if you cared about time-ordering events, and either include the idea of "now" relative to the enqueue time, with another received timestamp on the system where the data was enqueued. This would work for ordering stock transactions, for example, because if your order gets there later than Bob's order, it doesn't matter: you lose.
I'm uncertain how to respond on clustering; it would really depend on what you are talking about clustering, and your cluster architecture, but I see no reason that knowing what time it is is somehow more valuable than, say, load average on a given node. If you care, you include it in the cluster-sync information (no need for NTP, since you're already dealing with syncing a *lot* more information than just the time, and so time gets a "free ride" on the clustering protocol.
Expirations are all relative to the time of issue. Unless you are talking about something like X.509 certs, in which case, the issue is only relevant to the person signing the cert getting payed at intervals, and you'd otherwise just look at the CRL for the CERT, and if you couldn't contact the site that owned the CRL, you have to assume revocation anyway. But yeah, I'd call that a calendaring problem. Leases can be handled by op locks; that's how NFSv3 + leases handled them, and it's how SMB handles them today; the only thing you care about there is breaking the lease, and that's a relative time and/or "Now" event.
Tokens are handleable at the protocol level. The token issuer issues a relative timestamp, and you can compute a relative local stamp to decide when to ask for a renewal (just like DHCP leases are handled), or, you can eat the error handling when you try to use an invalid token, and as part of the error handler, ask to renew then.
"Practically everything my computer is doing" can be done in local relative time; unless I want a remote resource, all my local resources can be handled in relative time, and if I decide I actually give a damn, then I can worry about something like NTP, if I'm too cheap to buy a GPS receiver and/or something that can receive the time base broadcasts from my local cell tower (assuming I don't already have a cellular or WiFi in the computer, because otherwise, I just consult those).
And I think you are confusing "this is the current wall clock" with "I need to handle the switch debounce within 60ns" or "I need to do a context switch when the LBOLT fires", which are not things NTP would be/should be involved with.
PS: An engineer on LinkedIn was getting all angsty about an IOT device that he was worried about setting the timezone on. I convinced him to just put his log timestamps in UCT, and he was still angsting about what to put up for the time on the LCD, and I suggested he either put "UCT" after the time display, or... just don't display the time. There's actually no great reason to have *another damn human readable clock* on his LCD just to have something to display, since we are completely outnumbered by human readable clocks practically everywhere in our daily living environment, and if a human wants to know the time, they can look at one of those.
There are 3 types of time that matter to computers:
(1) "Now" - which doesn't need time sync
(2) "Relative to now" - which also does not need time sync
(3) "Absolute time" -this one needs time sync, and is typically only an issue for calendaring and scheduling.
If you're an astronomer, absolute time maters - or actually, "Local Apparent Sidereal Time", which also ties it to a specific longitude and latitude, so that you know where to point your telescope.
Most applications of time on computers fall into category #1 or #2; this includes *ALL* filesystem operations, and most other operations not related. Even calendaring is not an issue, if you use a mobile device (which can sync to the server providing network service, so long as it's not direct satellite), OR if you use a web client (in which case all dates are server dates anyway, and there's no such thing as client dates).
Face it, it's a design problem for about 95% of all applications in use today.
Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.
Only if you do not also update the Kerberos protocol.
And for some items,you don't need exactly the same. Broadcom is not the only one with touchscreens.
No. But they're the on;ly one that's capable of running the touchscreen firmware blob your pirated version of iOS is going to shove down to the chip every time the thing boots.
(1) $7,000/month * 12 months + additional $12,000/year = $96,000/year, not including any other contributions that come into his non-profit on top of that.
(2) Most of the need for NTP is driven by bad protocol design in client/server software.
NFS, for example, would not need synchronized time if the client would include a "this is my idea of the current time" timestamp in time related requests, e.g. "set mtime".
The server then does:
(clients idea of current time) - (clients desired mtime) + (servers idea of current time) = mtime to set on server
Voila: everything is consistent, clocks don't need synchronized between the client and the server.
Bonus points: network latency adjustment is automatic; no need to go off and implement PTP to get an even more precise version of NTP.
So most of this is a problem we've brought on ourselves by stupidly assuming a client and a server need synchronized time values in the first place, and then designing asinine protocol that build this assumption into the infrastructure built on top of those protocols.
Maybe instead of making NTP more reliable - at a pretty high expense for the small town in Oregon where he lives, and the cost of living is relatively low - we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?
PS: Yes, I brought this issue up in the IETF when NFSv4 was being designed in the first place.
So tell me again how a music festival is going to congest the airwaves and spectrum? Lets get specific. Are they suggesting that their equipment will drown out all 2.4Ghz or 5Ghz signals?
Yes.
So do not sit in front of the speakers, unless you want to be microwaved to death.
Over time, they should end up costing less. Unless you don't pay for your electricity.
If these things lasted 20 years, I definitely would want to have to wait until year 18 for them to "cost less" due to their amortized costs. Please do not include amortized costs of electrictiy in your calculation of bulb rices; you can't possibly predict what electricity will/won't cost of that time frame.
But there are a couple of drawbacks: First of all, the light color isn't very uniform. I have a bulb where one of the two "filaments" is more bluish than the other, and there's also variability between bulbs. Secondly, they flicker with the mains frequency (50Hz in Europe). Thirdly, there are no matte versions because the illumination is not evenly distributed and this would show up as shadows on the matte bulb. Of course this also means the room isn't illuminated evenly, so they are best used in lamps with several sockets, where this effect evens out somewhat. They are great for chandeliers and other lamps with exposed bulbs though. IMHO the flickering is the biggest problem.
IMHO, it's the coloring. I read a lot of real books, and in so doing, I prefer a particular (fairly broad) spectrum of light to prevent eyestrain.
The uneven illumination distribution could be fixed in a matte bulb, but you'd be paying a lot for the bulb due to the expense of the interior diffusive coating to achieve the effect.
The flickering is the driver circuitry (as aXis100 said), but it's because the bulbs are being designed primarily for the U.S. market, which means 110v 60Hz, and they tend to operate poorly outside that range. You can buy bulbs for the European market that have driver circuitry that doesn't "skip" like this, but they are going to tend to be more expensive (most of the U.S. bulbs in Europe are "grey market" imports due to the VAT that you pay for non-EU manufactured products).
You could find a better pixel density... why would anyone want to downgrade?
So the Apple software doesn't look like crap when you run it on your pseudo-Apple Watch.
With an ARM processor anyone can license... Big deal it doesn't come from one particular company -- hundred of others have no problems...
Apple has the best memory bandwidth of any ARM processor, period. Samsung is trying to catch up, but they are far from achieving it, and at nowhere near the power and thermal profile Apple has. Apple place their parts based on thermal budget, not based on shortest wire route. And they are number one at doing power management.
Also, 8 components? Like what? The CPU is about the only thing they design. Camera? That's Sony. Display? Samsung. CPU? Probably Samsung again (yes, they may design it, but they don't have a fab).
There's almost nothing unique about the watch in terms of hardware...
You're dead wrong. I don't think you are understanding "lock up the supply chain", so I will explain.
(1) They do not buy all the parts they need for a production run. They buy *ALL* the parts, and *ALL* the future production for those parts. This is why there is so much SPAM from dickheads wanting to first-party source iPhone displays: Because they *simply can't do it, period*.
(2) The parts include the CPU, the flash parts, the display, the *machines capable of being used to make the display bezel at all*, the microswitches for the buttons, etc..
(3) When Apple went to laser cut their LED pinholes that they use to show the LED through the aluminum bod of some of their devices, *they bought *ALL* the lasers. Not just *SOME* of them. *ALL* of them, and the production for the remainder of the year.
(4) Do you want to build a power supply for charging the thing? Sorry, you can't *GET* the connector.
(5) Do you want to build something that can *USE* one of Apple's power supplies? Again, sorry, yuou can't *GET* the other connector, either.
(6) Do you want to buy the Broadcom chip they use in their touch interfaces on the bezels and their trackpad on their laptops? Sorry *BROADCOM* on't sell you the chips.
Do you get it now?
It's the same thing IBM under Lou Gerstner used to do with the ThinkPads, before they sold that division off to Lenovo.
Apple has a monopoly on building hardware that will work with their software. Nothing you can do about it.
Maybe: It wouldn't be surprising if they were from the "3rd shift" from the "official" apple factory.
They're not. Apple products don't get "third shifted", because Apple controls the supply chain for at least 8 components of each of their products. You could get a display that looked similar, but it wouldn't have the same pixel density horizontally and vertically. Or you could get an integrated SIP/SOC, but it wouldn't be an S1. And it's apparently at *least* a 32 bit ARM system, since it's running a ported version of iOS.
One thing Tim Cook has *always* been good at is locking up the product parts suppliers, specifically to avoid "third shift" tactics. That's not to say that there isn't "lossage" or "misidentification of good parts as "faulty & destroyed", but that's all locked up pretty tightly.
It's useless to learn pen testing... unless you also learn "pen fixing".
It's totally useless to know that there are problems there, but now how to fix them.
It's like going to a doctor, they tell you they have bad news and good news. The bad news is that you have cancer. The good news is that they scored 5 under par during their last round of golf. The second piece of information doesn't help resolve the first one. Unless you treat any disease you find, you haven't helped them, you've only made them feel like crap about something they can't do anything about on their own.
Typically, you want a "defense in depth" strategy, which means firewalls, DMZs, the whole nine yards. But learning how to use script kiddy tools to get in is not going to teach you the skills you are going to need if you want to keep someone else using those same script kiddy tools out.
It takes an almost entirely different mindset, and it does, in fact, take real skills -- almost the same skills you'd need to write those tools yourself, in order to write the code necessary to fix the problem so it can no longer happen. In other words, you not only have to know how the tool is getting in, to keep the tool from getting in. This can require substantial knowledge in systems and network architecture, and, if the way the tool happens to get in is via SQL injection, cross-site scripting, etc., etc., you will likely have to *minimally* know enough about the technology that's being exploited that you can fix it.
This is not the job for a single individual; it's a job for a team of at least several people (if they are incredibly good), or potentially a *lot* of people, if they are individually specialized to the point of being narrowly focussed in being able to go deep in only one or two areas.
The best advice I could give you is advice you are no longer able to take: learn this stuff while you are a minor, and unlikely to be put away for a felony, or learn this stuff prior to the electronic trespass laws going into effect in the mid to late 1980's. Both of these mean you've missed your window on getting a broad base of experience on a lot of disparate systems, of the type you'd be asked to pen test (or subsequently "pen fix").
Unless you are really wealthy - or your company is - and you are able to set up a lot of systems which, when you hack them, there's no risk that you'll end up in jail.
Other than that - there's some training available, but if you want to fix the problems you find, you have to think about systems as a gestalt, and you'll have to learn about networking and at least some types of programming, probably in considerable depth, to make up for your inability to legally acquire breadth, and then hire people to get breadth on your team.
Alternately, realize what I did the first day of kindergarten: I didn't want to go back after the first day "because they would not give me reading, writing, and arithmetic". In other words, this is not knowledge that someone can gift you with, it's knowledge that you'll have to fight to acquire, and it's not going to be easy for you.
OTOH they have PLENTY of reason to upgrade. Heartbleed, freak, shellshock, etc. Tons of bugs found in Linux/Windows/Apple/Android on a day-to-day basis.
You're assuming it is "up".
New bugs are not necessarily better than old ones.
The pressing question though is whether there's a void for someone else to fill if Google starts making Android a true iOS clone by nixing sideloading. They've inched closer than ever with Lollipop, and I don't see that changing going forward. Meanwhile, no sideloading means that Amazon loses whatever Android customers were using Android phones. While the Fire tablets are surely the biggest slice of the Amazon App Store/Music Store pie, I don't know if they'd just pack up and go home if Google locked them out. Conversely, I don't know if the disappearance of F-Droid, Appbrain, AAS, and other third party app stores would be the tipping point that would prevent people from pining for the Galaxy S7.
Is Android too big to fail? At this point, I'm stuck saying 'yes', at least for now.
It's a difficult question.
Can you side-load on an iPhone? Yes, you can. There are three ways:
(1) Jailbreak the device; some people are willing to do this. The preeminent reason is to work around carrier limitations on tethering/hotspotting to get around the fact that the carrier has unlimited data on some phone plans, but either does not permit, or has capped charges for, tethering/hotspotting through the phone, or through mobile hotspots. Other than a few applications to work around Apple/carrier agreements, or add functionality Apple doesn't/won't approve, this is not so big these days.
(2) Enroll the device as a developer device using a developer certificate. This allows you a limited number of devices, however, and isn't useful for wide scale distribution. It's a dead end.
(3) Enroll the device as an enterprise device. There are already Chinese "app stores" which do this; you enroll voluntarily, or the phone comes already enrolled when you purchase it from the vendor, and they install an enterprise cert, signed by Apple, which allows them to run their own distribution system. Typically, they pirate U.S. Apps, rewrap them, resign them, and then sell them on the cheap, giving no money back to the authors. In addition, there's often malware included with the applications sold this way. Apple hates it, and I have no doubt, there's active work on enterprise support to prevent this, going forward.
So side-loading isn't the biggest issue, since if there's a will, there's a way, and Android would also end up with methods similar to these thre to increase the difficult of, but not eliminate, side-loading.
The flip side of this is that, unless they do something, the pure *volume* of malware for Android will almost certainly kill their viability as an app platform eventually, even if it's not going to happen today or tomorrow.
The biggest problem with Android, with regard to apps, is that there are are too many targets.
Apple is in the process of screwing themselves over this way, for short term monetary gains that will likely not have long term value for them. At a minimum, a developer has to target 7 iOS platforms at this point in time - even if that ends up being wrapped up in a single distribution package, so it looks like a single thing in the App store. In addition, video content is split between 4:3 and 16:9 aspect ratios. Apple eats the transcoding costs and the duplicate CDN costs for these, but the decision to change the device means twice as much content has to be carried around.
But 7 is manageable, if you are targeting the same OS version, or an earlier but forward compatible OS version for all devices.
The Android ecosystem is the wild west, in comparison. And automatic updating of Android versions on older devices won't gloss over hardware differences in input methods, sensors, and so on.
So...
(1) Yes, there's room. If Samsung wanted to own this, they probably could, just by standardizing minimal feature set on their entire product line, and then forcing version updates on the carrier, or making sufficiently compelling new devices that the carrier doesn't think the version updates will impact their 18 month
Nope it's google's fault. In order to go the whole hog and have all the google apps etc, the vendors have to do certain things.
You mean change these things?
Carrier business model:
(1) Contractually obligate you for 2 years (2) Entice you with "upgraded phone" every 18 months (3) Prevent them upgrading their own phone and escaping carrier lock-in after 2 years (4) Benefit from customer lock in (5) Goto 2
Cell phone vendor business model:
(1) Bring a new phone to market (2) Contract with a carrier/seller who considers it enough of an upgrade to entice an early re-up on a customer contract (3) Start work on the next phone to sell more hardware (4) Goto 1
Phone OS vendor business model:
(1) Continuously work on the OS (2) Convince cell phone vendor to use OS (3) Cell phone vendor takes snapshot of tree (3)(a) Cell phone vendor productizes snapshot, because OS vendor could not produce a finished product to save their mother (4) Goto 1
Admittedly, Google would *like* to change things, but at this point, it's really kind of too late; they should have started with lock-in to their own App store.
Apple doesn't have this problem because the next iPhone only has to compete with the previous iPhone, and Apple *actually* tends to improve the iPhone hardware in a less-than 18 month cycle (which keeps the carriers happy), and it doesn't have to fight with all the other cell phone vendors for mind share because, hey, where else are you going to run all those apps/listen to all that music/watch all those movies, that you've already paid for.
Apple has App-based lock-in, and 18 month upgrade cycle carrier satisfaction, and they sell both the hardware and the software, so there's no hardware company to push-back on software updates, and there's no PITA continuous development cycle that prevents software updates from being polished products to push back the other direction.
Google could *probably*, *eventually* fix things, if they were willing to swallow some incredibly bitter pills, and if they were to do profit-sharing of App revenue with the hardware vendors so that the hardware vendors for Android device were willing to be commoditized, but... it would be an incredibly bitter pill, to have to change their development model away from waterfall, and it would be an incredibly bitter pill to lock down Apps and side-loading.
Too bad you didn't step up to the plate and become the maintainer, when Google offered to give the source code away to anyone who wanted to run their own "Google Reader" service.
It is not a problem of code, it is a problem of providing the service
When Google originally offered the code, they offered to host it on Google's hosted infrastructure service for a year, at no charge, until the project got up on its feet. There were no takers.
This will probably be moderated down as well... however, yes, "providing the service" is *exactly* the problem, and it's *exactly* why Google cancelled the thing when the back end hosting infrastructure APIs changed out from under the (unmaintained) Reader codebase. The maintainers had moved onto other projects.
And while Google could have either brought them back (the ones who wanted to revisit their old code), or they could have put new hires on the porting problem, and gotten Reader back on its feet on the new hosting infrastructure, it wouldn't have solved the basic problem.
The basic problem is that there was no sustainable revenue model for the service. Google's Reader service allowed the use of any client that someone cared to write, and a heck of a lot of people wanted to write clients that excluded advertising as a means of supporting the costs of running the service. Which would be fine, if there were any way to charge for it, *other* than advertising, which didn't break the client/back-end-service model, which is what people *liked most* about Reader in the first place.
So Google didn't throw good money after bad, and no one else stepped up to throw good money after bad, and (possibly) figure out some other way to monetize the service, such as changing the over the wire representation such that advertising was indistinguishable from content. Which wouldn't have worked, since that would just trigger an arms race for clever advertising exclusionary filtering in the display services, instead of at the protocol level.
So you're right: "it is a problem of providing the service", and the specific problem is "no one wanted to pay to do that".
Abandoned while new devices with those versions are still being sold.
Those aren't "new devices", those are "old devices, still being manufactured by vendors who are unable to come up with new devices in a timely fashion", or they are "old devices that used to live in a warehouse, and which are now being sold at a discount, because no one would buy them otherwise".
Too bad you didn't step up to the plate and become the maintainer, when Google offered to give the source code away to anyone who wanted to run their own "Google Reader" service.
I guess you maybe couldn't figure out a revenue model for the damn thing, either?
I find that code is processed through the same part of my brain that processes music. If you play music, my code will go to crap, since I'm trying to do two things with the same set of neurons.
I totally can not understand how people can produce code while listening to music.
OK, I lied; what I can't understand is how people can produce GOOD code while listening to music.
Apple has been talking about this for a long time.
You really don't want your security people to be contract workers; they have access, at least at the supervisory level, to all sorts of sensitive areas of your building, including Jony Ive's office in the design wing, where they could happily use their phones to photograph prototypes.
Google began talking about doing this about three years ago, when they switched to the same contract security firm Apple used, and the Apple/Google relationship started to become more and more adversarial on top of that (I knew the supervisory staff, and many of the individual contractors at Apple, and recognized them when they came to work for Google.
I think this is being done more to prevent industrial espionage, than anything else.
At both Apple and Google, we moved our trash outside explicitly sensitive secure areas at night, so that the janitorial staff avoided entry. For a lot of it, it was honor system (if you count being on camera but not having a lurking linebacker ready to take you out if you make a wrong move, as "honor system"), where the secure offices without physical electronic security locks has a red sticky dot placed above the room doorknob to prevent people trying to go in.
This also has dick-all to do with any kind of "gentrification" issues that the article claims, since most of the people I know who worked security lived East Bay, and many of them owned their own houses.
Slashdot Mirror
Sounds like the issue is that certs have expiration dates -- which is dumb.
"I trust you today, in 2017 I won't though."
That is just asinine. Either the two sides trust each other or not, the "current date" of the clock on either side should not invalidate that trust.
Great! NOW How is VeriSign supposed to make money, if they can't charge you over and over again every year for the same thing, where only the expiration date and signature block are different? 1/2 8-)
I'm just staring at your comment and blinking, because...wow. Even if I ignore #1&2, #3..."and is typically only an issue for calendaring and scheduling." How about queuing? How about clustering? How about expiration of millions of things (tokens, certs, leases, etc). How about practically everything your computer is doing? Unless you're meaning to say that everything really does boil down to "calendaring" and "scheduling," and you're not just making some Outlook comment. If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.
IT's not an issue for queueing; you enqueue things "now". So, for example, you could modify IBM's MQSeries, if you cared about time-ordering events, and either include the idea of "now" relative to the enqueue time, with another received timestamp on the system where the data was enqueued. This would work for ordering stock transactions, for example, because if your order gets there later than Bob's order, it doesn't matter: you lose.
I'm uncertain how to respond on clustering; it would really depend on what you are talking about clustering, and your cluster architecture, but I see no reason that knowing what time it is is somehow more valuable than, say, load average on a given node. If you care, you include it in the cluster-sync information (no need for NTP, since you're already dealing with syncing a *lot* more information than just the time, and so time gets a "free ride" on the clustering protocol.
Expirations are all relative to the time of issue. Unless you are talking about something like X.509 certs, in which case, the issue is only relevant to the person signing the cert getting payed at intervals, and you'd otherwise just look at the CRL for the CERT, and if you couldn't contact the site that owned the CRL, you have to assume revocation anyway. But yeah, I'd call that a calendaring problem. Leases can be handled by op locks; that's how NFSv3 + leases handled them, and it's how SMB handles them today; the only thing you care about there is breaking the lease, and that's a relative time and/or "Now" event.
Tokens are handleable at the protocol level. The token issuer issues a relative timestamp, and you can compute a relative local stamp to decide when to ask for a renewal (just like DHCP leases are handled), or, you can eat the error handling when you try to use an invalid token, and as part of the error handler, ask to renew then.
"Practically everything my computer is doing" can be done in local relative time; unless I want a remote resource, all my local resources can be handled in relative time, and if I decide I actually give a damn, then I can worry about something like NTP, if I'm too cheap to buy a GPS receiver and/or something that can receive the time base broadcasts from my local cell tower (assuming I don't already have a cellular or WiFi in the computer, because otherwise, I just consult those).
And I think you are confusing "this is the current wall clock" with "I need to handle the switch debounce within 60ns" or "I need to do a context switch when the LBOLT fires", which are not things NTP would be/should be involved with.
PS: An engineer on LinkedIn was getting all angsty about an IOT device that he was worried about setting the timezone on. I convinced him to just put his log timestamps in UCT, and he was still angsting about what to put up for the time on the LCD, and I suggested he either put "UCT" after the time display, or ... just don't display the time. There's actually no great reason to have *another damn human readable clock* on his LCD just to have something to display, since we are completely outnumbered by human readable clocks practically everywhere in our daily living environment, and if a human wants to know the time, they can look at one of those.
There are 3 types of time that matter to computers:
(1) "Now" - which doesn't need time sync
(2) "Relative to now" - which also does not need time sync
(3) "Absolute time" -this one needs time sync, and is typically only an issue for calendaring and scheduling.
If you're an astronomer, absolute time maters - or actually, "Local Apparent Sidereal Time", which also ties it to a specific longitude and latitude, so that you know where to point your telescope.
Most applications of time on computers fall into category #1 or #2; this includes *ALL* filesystem operations, and most other operations not related. Even calendaring is not an issue, if you use a mobile device (which can sync to the server providing network service, so long as it's not direct satellite), OR if you use a web client (in which case all dates are server dates anyway, and there's no such thing as client dates).
Face it, it's a design problem for about 95% of all applications in use today.
Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.
Only if you do not also update the Kerberos protocol.
And for some items,you don't need exactly the same. Broadcom is not the only one with touchscreens.
No. But they're the on;ly one that's capable of running the touchscreen firmware blob your pirated version of iOS is going to shove down to the chip every time the thing boots.
I have two problems with this article.
(1) $7,000/month * 12 months + additional $12,000/year = $96,000/year, not including any other contributions that come into his non-profit on top of that.
(2) Most of the need for NTP is driven by bad protocol design in client/server software.
NFS, for example, would not need synchronized time if the client would include a "this is my idea of the current time" timestamp in time related requests, e.g. "set mtime".
The server then does:
(clients idea of current time) - (clients desired mtime) + (servers idea of current time) = mtime to set on server
Voila: everything is consistent, clocks don't need synchronized between the client and the server.
Bonus points: network latency adjustment is automatic; no need to go off and implement PTP to get an even more precise version of NTP.
So most of this is a problem we've brought on ourselves by stupidly assuming a client and a server need synchronized time values in the first place, and then designing asinine protocol that build this assumption into the infrastructure built on top of those protocols.
Maybe instead of making NTP more reliable - at a pretty high expense for the small town in Oregon where he lives, and the cost of living is relatively low - we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?
PS: Yes, I brought this issue up in the IETF when NFSv4 was being designed in the first place.
So tell me again how a music festival is going to congest the airwaves and spectrum? Lets get specific. Are they suggesting that their equipment will drown out all 2.4Ghz or 5Ghz signals?
Yes.
So do not sit in front of the speakers, unless you want to be microwaved to death.
cost about the same as incandescent light bulbs?
Over time, they should end up costing less. Unless you don't pay for your electricity.
If these things lasted 20 years, I definitely would want to have to wait until year 18 for them to "cost less" due to their amortized costs. Please do not include amortized costs of electrictiy in your calculation of bulb rices; you can't possibly predict what electricity will/won't cost of that time frame.
But there are a couple of drawbacks: First of all, the light color isn't very uniform. I have a bulb where one of the two "filaments" is more bluish than the other, and there's also variability between bulbs. Secondly, they flicker with the mains frequency (50Hz in Europe). Thirdly, there are no matte versions because the illumination is not evenly distributed and this would show up as shadows on the matte bulb. Of course this also means the room isn't illuminated evenly, so they are best used in lamps with several sockets, where this effect evens out somewhat. They are great for chandeliers and other lamps with exposed bulbs though. IMHO the flickering is the biggest problem.
IMHO, it's the coloring. I read a lot of real books, and in so doing, I prefer a particular (fairly broad) spectrum of light to prevent eyestrain.
The uneven illumination distribution could be fixed in a matte bulb, but you'd be paying a lot for the bulb due to the expense of the interior diffusive coating to achieve the effect.
The flickering is the driver circuitry (as aXis100 said), but it's because the bulbs are being designed primarily for the U.S. market, which means 110v 60Hz, and they tend to operate poorly outside that range. You can buy bulbs for the European market that have driver circuitry that doesn't "skip" like this, but they are going to tend to be more expensive (most of the U.S. bulbs in Europe are "grey market" imports due to the VAT that you pay for non-EU manufactured products).
You're so right.
You could find a better pixel density... why would anyone want to downgrade?
So the Apple software doesn't look like crap when you run it on your pseudo-Apple Watch.
With an ARM processor anyone can license... Big deal it doesn't come from one particular company -- hundred of others have no problems...
Apple has the best memory bandwidth of any ARM processor, period. Samsung is trying to catch up, but they are far from achieving it, and at nowhere near the power and thermal profile Apple has. Apple place their parts based on thermal budget, not based on shortest wire route. And they are number one at doing power management.
Also, 8 components? Like what? The CPU is about the only thing they design. Camera? That's Sony. Display? Samsung. CPU? Probably Samsung again (yes, they may design it, but they don't have a fab).
There's almost nothing unique about the watch in terms of hardware...
You're dead wrong. I don't think you are understanding "lock up the supply chain", so I will explain.
(1) They do not buy all the parts they need for a production run. They buy *ALL* the parts, and *ALL* the future production for those parts. This is why there is so much SPAM from dickheads wanting to first-party source iPhone displays: Because they *simply can't do it, period*.
(2) The parts include the CPU, the flash parts, the display, the *machines capable of being used to make the display bezel at all*, the microswitches for the buttons, etc..
(3) When Apple went to laser cut their LED pinholes that they use to show the LED through the aluminum bod of some of their devices, *they bought *ALL* the lasers. Not just *SOME* of them. *ALL* of them, and the production for the remainder of the year.
(4) Do you want to build a power supply for charging the thing? Sorry, you can't *GET* the connector.
(5) Do you want to build something that can *USE* one of Apple's power supplies? Again, sorry, yuou can't *GET* the other connector, either.
(6) Do you want to buy the Broadcom chip they use in their touch interfaces on the bezels and their trackpad on their laptops? Sorry *BROADCOM* on't sell you the chips.
Do you get it now?
It's the same thing IBM under Lou Gerstner used to do with the ThinkPads, before they sold that division off to Lenovo.
Apple has a monopoly on building hardware that will work with their software. Nothing you can do about it.
Maybe: It wouldn't be surprising if they were from the "3rd shift" from the "official" apple factory.
They're not. Apple products don't get "third shifted", because Apple controls the supply chain for at least 8 components of each of their products. You could get a display that looked similar, but it wouldn't have the same pixel density horizontally and vertically. Or you could get an integrated SIP/SOC, but it wouldn't be an S1. And it's apparently at *least* a 32 bit ARM system, since it's running a ported version of iOS.
One thing Tim Cook has *always* been good at is locking up the product parts suppliers, specifically to avoid "third shift" tactics. That's not to say that there isn't "lossage" or "misidentification of good parts as "faulty & destroyed", but that's all locked up pretty tightly.
It's useless to learn pen testing... unless you also learn "pen fixing".
It's totally useless to know that there are problems there, but now how to fix them.
It's like going to a doctor, they tell you they have bad news and good news. The bad news is that you have cancer. The good news is that they scored 5 under par during their last round of golf. The second piece of information doesn't help resolve the first one. Unless you treat any disease you find, you haven't helped them, you've only made them feel like crap about something they can't do anything about on their own.
Typically, you want a "defense in depth" strategy, which means firewalls, DMZs, the whole nine yards. But learning how to use script kiddy tools to get in is not going to teach you the skills you are going to need if you want to keep someone else using those same script kiddy tools out.
It takes an almost entirely different mindset, and it does, in fact, take real skills -- almost the same skills you'd need to write those tools yourself, in order to write the code necessary to fix the problem so it can no longer happen. In other words, you not only have to know how the tool is getting in, to keep the tool from getting in. This can require substantial knowledge in systems and network architecture, and, if the way the tool happens to get in is via SQL injection, cross-site scripting, etc., etc., you will likely have to *minimally* know enough about the technology that's being exploited that you can fix it.
This is not the job for a single individual; it's a job for a team of at least several people (if they are incredibly good), or potentially a *lot* of people, if they are individually specialized to the point of being narrowly focussed in being able to go deep in only one or two areas.
The best advice I could give you is advice you are no longer able to take: learn this stuff while you are a minor, and unlikely to be put away for a felony, or learn this stuff prior to the electronic trespass laws going into effect in the mid to late 1980's. Both of these mean you've missed your window on getting a broad base of experience on a lot of disparate systems, of the type you'd be asked to pen test (or subsequently "pen fix").
Unless you are really wealthy - or your company is - and you are able to set up a lot of systems which, when you hack them, there's no risk that you'll end up in jail.
Other than that - there's some training available, but if you want to fix the problems you find, you have to think about systems as a gestalt, and you'll have to learn about networking and at least some types of programming, probably in considerable depth, to make up for your inability to legally acquire breadth, and then hire people to get breadth on your team.
Alternately, realize what I did the first day of kindergarten: I didn't want to go back after the first day "because they would not give me reading, writing, and arithmetic". In other words, this is not knowledge that someone can gift you with, it's knowledge that you'll have to fight to acquire, and it's not going to be easy for you.
I occasionally get email from Google "we notice you're still using Talk. Please switch to Hangouts". So far I've been able to ignore it.
SO many apps are missing a "Fuck You" button... Just saying.
OTOH they have PLENTY of reason to upgrade. Heartbleed, freak, shellshock, etc. Tons of bugs found in Linux/Windows/Apple/Android on a day-to-day basis.
You're assuming it is "up".
New bugs are not necessarily better than old ones.
The OS people are quite often right. Not this time, though.
We (OS people) are always right. Always. And if you don't like it, "patches welcome" or lump it.
The pressing question though is whether there's a void for someone else to fill if Google starts making Android a true iOS clone by nixing sideloading. They've inched closer than ever with Lollipop, and I don't see that changing going forward. Meanwhile, no sideloading means that Amazon loses whatever Android customers were using Android phones. While the Fire tablets are surely the biggest slice of the Amazon App Store/Music Store pie, I don't know if they'd just pack up and go home if Google locked them out. Conversely, I don't know if the disappearance of F-Droid, Appbrain, AAS, and other third party app stores would be the tipping point that would prevent people from pining for the Galaxy S7.
Is Android too big to fail? At this point, I'm stuck saying 'yes', at least for now.
It's a difficult question.
Can you side-load on an iPhone? Yes, you can. There are three ways:
(1) Jailbreak the device; some people are willing to do this. The preeminent reason is to work around carrier limitations on tethering/hotspotting to get around the fact that the carrier has unlimited data on some phone plans, but either does not permit, or has capped charges for, tethering/hotspotting through the phone, or through mobile hotspots. Other than a few applications to work around Apple/carrier agreements, or add functionality Apple doesn't/won't approve, this is not so big these days.
(2) Enroll the device as a developer device using a developer certificate. This allows you a limited number of devices, however, and isn't useful for wide scale distribution. It's a dead end.
(3) Enroll the device as an enterprise device. There are already Chinese "app stores" which do this; you enroll voluntarily, or the phone comes already enrolled when you purchase it from the vendor, and they install an enterprise cert, signed by Apple, which allows them to run their own distribution system. Typically, they pirate U.S. Apps, rewrap them, resign them, and then sell them on the cheap, giving no money back to the authors. In addition, there's often malware included with the applications sold this way. Apple hates it, and I have no doubt, there's active work on enterprise support to prevent this, going forward.
So side-loading isn't the biggest issue, since if there's a will, there's a way, and Android would also end up with methods similar to these thre to increase the difficult of, but not eliminate, side-loading.
The flip side of this is that, unless they do something, the pure *volume* of malware for Android will almost certainly kill their viability as an app platform eventually, even if it's not going to happen today or tomorrow.
The biggest problem with Android, with regard to apps, is that there are are too many targets.
Apple is in the process of screwing themselves over this way, for short term monetary gains that will likely not have long term value for them. At a minimum, a developer has to target 7 iOS platforms at this point in time - even if that ends up being wrapped up in a single distribution package, so it looks like a single thing in the App store. In addition, video content is split between 4:3 and 16:9 aspect ratios. Apple eats the transcoding costs and the duplicate CDN costs for these, but the decision to change the device means twice as much content has to be carried around.
But 7 is manageable, if you are targeting the same OS version, or an earlier but forward compatible OS version for all devices.
The Android ecosystem is the wild west, in comparison. And automatic updating of Android versions on older devices won't gloss over hardware differences in input methods, sensors, and so on.
So...
(1) Yes, there's room. If Samsung wanted to own this, they probably could, just by standardizing minimal feature set on their entire product line, and then forcing version updates on the carrier, or making sufficiently compelling new devices that the carrier doesn't think the version updates will impact their 18 month
Nope it's google's fault. In order to go the whole hog and have all the google apps etc, the vendors have to do certain things.
You mean change these things?
Carrier business model:
(1) Contractually obligate you for 2 years
(2) Entice you with "upgraded phone" every 18 months
(3) Prevent them upgrading their own phone and escaping carrier lock-in after 2 years
(4) Benefit from customer lock in
(5) Goto 2
Cell phone vendor business model:
(1) Bring a new phone to market
(2) Contract with a carrier/seller who considers it enough of an upgrade to entice an early re-up on a customer contract
(3) Start work on the next phone to sell more hardware
(4) Goto 1
Phone OS vendor business model:
(1) Continuously work on the OS
(2) Convince cell phone vendor to use OS
(3) Cell phone vendor takes snapshot of tree
(3)(a) Cell phone vendor productizes snapshot, because OS vendor could not produce a finished product to save their mother
(4) Goto 1
Admittedly, Google would *like* to change things, but at this point, it's really kind of too late; they should have started with lock-in to their own App store.
Apple doesn't have this problem because the next iPhone only has to compete with the previous iPhone, and Apple *actually* tends to improve the iPhone hardware in a less-than 18 month cycle (which keeps the carriers happy), and it doesn't have to fight with all the other cell phone vendors for mind share because, hey, where else are you going to run all those apps/listen to all that music/watch all those movies, that you've already paid for.
Apple has App-based lock-in, and 18 month upgrade cycle carrier satisfaction, and they sell both the hardware and the software, so there's no hardware company to push-back on software updates, and there's no PITA continuous development cycle that prevents software updates from being polished products to push back the other direction.
Google could *probably*, *eventually* fix things, if they were willing to swallow some incredibly bitter pills, and if they were to do profit-sharing of App revenue with the hardware vendors so that the hardware vendors for Android device were willing to be commoditized, but ... it would be an incredibly bitter pill, to have to change their development model away from waterfall, and it would be an incredibly bitter pill to lock down Apps and side-loading.
Too bad you didn't step up to the plate and become the maintainer, when Google offered to give the source code away to anyone who wanted to run their own "Google Reader" service.
It is not a problem of code, it is a problem of providing the service
When Google originally offered the code, they offered to host it on Google's hosted infrastructure service for a year, at no charge, until the project got up on its feet. There were no takers.
This will probably be moderated down as well... however, yes, "providing the service" is *exactly* the problem, and it's *exactly* why Google cancelled the thing when the back end hosting infrastructure APIs changed out from under the (unmaintained) Reader codebase. The maintainers had moved onto other projects.
And while Google could have either brought them back (the ones who wanted to revisit their old code), or they could have put new hires on the porting problem, and gotten Reader back on its feet on the new hosting infrastructure, it wouldn't have solved the basic problem.
The basic problem is that there was no sustainable revenue model for the service. Google's Reader service allowed the use of any client that someone cared to write, and a heck of a lot of people wanted to write clients that excluded advertising as a means of supporting the costs of running the service. Which would be fine, if there were any way to charge for it, *other* than advertising, which didn't break the client/back-end-service model, which is what people *liked most* about Reader in the first place.
So Google didn't throw good money after bad, and no one else stepped up to throw good money after bad, and (possibly) figure out some other way to monetize the service, such as changing the over the wire representation such that advertising was indistinguishable from content. Which wouldn't have worked, since that would just trigger an arms race for clever advertising exclusionary filtering in the display services, instead of at the protocol level.
So you're right: "it is a problem of providing the service", and the specific problem is "no one wanted to pay to do that".
Perhaps this is fixable...
Could you maybe write:
"'Articles': What It Takes To Write an Article Not Light On Details"
?
Abandoned while new devices with those versions are still being sold.
Those aren't "new devices", those are "old devices, still being manufactured by vendors who are unable to come up with new devices in a timely fashion", or they are "old devices that used to live in a warehouse, and which are now being sold at a discount, because no one would buy them otherwise".
I miss Google Reader, their RSS reader.
Too bad you didn't step up to the plate and become the maintainer, when Google offered to give the source code away to anyone who wanted to run their own "Google Reader" service.
I guess you maybe couldn't figure out a revenue model for the damn thing, either?
How to totally screw up my ability to code:
(1) Play music
(2) There is no step 2
I find that code is processed through the same part of my brain that processes music. If you play music, my code will go to crap, since I'm trying to do two things with the same set of neurons.
I totally can not understand how people can produce code while listening to music.
OK, I lied; what I can't understand is how people can produce GOOD code while listening to music.
Apple has been talking about this for a long time.
You really don't want your security people to be contract workers; they have access, at least at the supervisory level, to all sorts of sensitive areas of your building, including Jony Ive's office in the design wing, where they could happily use their phones to photograph prototypes.
Google began talking about doing this about three years ago, when they switched to the same contract security firm Apple used, and the Apple/Google relationship started to become more and more adversarial on top of that (I knew the supervisory staff, and many of the individual contractors at Apple, and recognized them when they came to work for Google.
I think this is being done more to prevent industrial espionage, than anything else.
At both Apple and Google, we moved our trash outside explicitly sensitive secure areas at night, so that the janitorial staff avoided entry. For a lot of it, it was honor system (if you count being on camera but not having a lurking linebacker ready to take you out if you make a wrong move, as "honor system"), where the secure offices without physical electronic security locks has a red sticky dot placed above the room doorknob to prevent people trying to go in.
This also has dick-all to do with any kind of "gentrification" issues that the article claims, since most of the people I know who worked security lived East Bay, and many of them owned their own houses.
But in all seriousness, I'm relieved that Mr. Ford has come out alive from the wreck and wish him a speed recovery.
Why do you want him to get trapped on a bus with Sandra Bullock, and be unable to slow down below 50 MPH?!?!?
A dazed and confused Harrison Ford staggered from the wreckage, grabbed a golf bag, and started walking away with it.
When challeneged by the golf bag's owner, he repeatedly yelled "It belongs in a museum!", until paramedics arrived.