With health care costs and benefits, doesn't it cost MORE to hire a full time worker than two part time workers?
We are talking about making 20 the new "full time", which would mean that your point doesn't apply.
But yes, this is one of the problems with the current Affordable Care Act unfunded mandates, as opposed to going to a single payer system, like the national health services in most of the rest of the world. The consequence of which, of course, is that AIG would have missed out on their TARP-style bailout for having everyone forced to purchase insurance from one of their member companies. Might have damaged someone's campaign contributions.
If you read the wiki that the article poster linked to, there are all sorts of caveats and missing functionality. "Properly Supported" means functional parity, and from where it sits right now, there is not functional parity.
What's the advantage to making a cheap device which people would buy to use as a display instead of a means of reading books purchased from B&N? I think they are also unlikely to build ones that can be used as BBQ grills.
As long as the device is sold at a small profit, or at minimum not at a loss, it's worth it to sell them to increase the distributed base. If you have the device for one purpose, you might use it for another. Plus, you get to claim the sales as... sales. It gets your volume up, so you can buy components at lower prices...
Unless it's a loss-leader for content sales for the device, or the additional sales drive costs down through economies of scale, you are WRONG: it is NOT worth it to sell them at a loss, even a small one.
If it's sold at a small profit, as in the device manufacturing process is self sustaining, then yes, it's probably worthwhile. But realize that self-sustaining in this regard includes amortized R&D costs, production tooling costs, manufacturing costs, shipping costs, and flooring costs for putting the devices inside the front door and having Nook sales areas inside physical B&N stores where you would otherwise have more books, a wider variety of titles, and other things which also compete for flooring, such as book bags, book lights, and so on. As a general rule, this COGS - Cost Of Goods Sold - will be twice the total of the parts costs and manufacturing costs to get the device into shrink-wrapped boxes.
My understanding is that Nooks are sold as a loss-leader in the expectation of future book sales. My undestanding comes from their 10Q and EDGAR filings with the US government, which are a matter of public record.
The whole "Internet bubble 1.0" dotbomb was about the non-viability of "sell at a loss, make it up in volume" business model. That business model was about capturing the market to the exclusion of competitors, and then raising prices, after which people will remain your customers out of early loyalty, or out of lack of choice in the matter.
The chinese restaurant "revolving door" in the small industrial park near my home is predicated on the same business model, and the reason I call it a "revolving door" is that the business model doesn't work. You get one restaurant in ant really low prices, then they establish a lunch crowd based on price, and then another restaurant opens in the park and undercuts the price, the first goes out of business, and the cycle repeats. These restaurants run on cash flow, or at a loss based on an initial investment which gets eaten up. The people in the park could care less, so long as they have a place to go for chinese food for lunch, and during the rare times there is no restaurant, they drive to the chinese place by the post office instead, and pay a higher price which is capable of sustaining the business there.
Personally, I would never sell a multifunction device where I'm not getting income from each function; it just doesn't make sense. That's why if you want to read.DOC files or.PDFs, it costs you for the extra software on the Nook, since if you are reading either of those, you aren't reading content purchased from B&N. The only way an unrestricted universal content reader makes sense is if it's sold at an at least 6% premium above COGS, and so far parts cost have kept that out of reach (this answers another question posed early on in the posts on this topic).
Consider a worker who could build 10 widgets a year and afford to buy 5 widgets back in "the old days." With improvements in technology, now a worker can build 50 widgets a year --- and gets paid enough to buy 4, because they're competing for jobs with all the other workers laid off who now can afford to buy 0.
Why didn't some of the laid off workers start 4 more businesses to soak up the additional productivity? Clearly, any worker they could hire would be 5 times more productive than before the change over, so now they can afford to start their won businesses and employ people, right?
I think you nailed it. The 8 hour workday needs to be shortened.
This might be workable......if you were able to make it so that it cost a company exactly the same to hire 2 workers @ 20 hours/week as it costs them to hire 1 worker @ 40 hours/week. Which means the government eats the individual per employee costs for the extra employees, as taxes which they do not collect.
Finally a device with a color e-ink display, pretty please? How about making it work as a computer display, too?
What's the advantage to making a cheap device which people would buy to use as a display instead of a means of reading books purchased from B&N? I think they are also unlikely to build ones that can be used as BBQ grills.
This is why terrorists are stupid. Damage an air conditioner, unprotected from a parachutist, on the outside of a DRAM plant = billions of dollars of economic damage.
How many candlelit vigils have have you seen organized for the loss of DRAM factory?
Now how many were there for the Boston bombings?
Terrorists aren't so stupid.
How many candlelit vigils does it take to result in a substantial change in US foreign policy, or the instrumentality used to implement said policy?
So how effective were those attacks, again? What substantive, measurable progress towards their goals was achieved? Are we even generally aware of the goals of the attack? If not, how can the US electorate impact the policy decisions of their elected officials in such a way as to preclude future attacks?
To be totally direct and unequivocal, those attacks were totally ineffective at achieving anything but lost work days and candle sales, which were unlikely the terrorists goals which motivated the attacks in the first place.
You're assuming that the objective of terrorism is to cause generalised harm. If that was the goal it'd be even easier for them to just stay at home and punch each other in the face.
A man can dream.
Anyway, to complete the thought: terrorism is about retribution, and about conveying a political message. Those actions have specific targets, and raising the price of memory does not necessarily affect those targets to the extent or with the specificity demanded.
Terrorism is a form of asymmetric warfare. All warfare is waged with a goal of defeating or disabling or stalling the enemy; whether you measure this as "toppling their government", "evidencing a strong threat of retribution for political intervention in a region/country not their own", or "causing the enemy to engage in domestic expenditures of resources and/or to engage in policies objectionable to its citizenry as a means of causing them to disengage from external matters" is irrelevant.
The 9/11 attacks were more or less effective at the third of those. They might have been effective at the second of these as a target goal as well, but the US general population is blithely unaware of the activities the US government takes in implementation of its foreign policy, if they are even aware of US foreign policy at all. This is manifestly evident in the US public perception of the Snowden revelations. Clearly, the government became aware fairly quickly of the perpetrators, and were they persuadable on #2 at all, they were (apparently) not persuaded. Quite the opposite.
Perhaps the next set of terrorists will take that lesson to heart, and make an announcement prior to an attack regarding their demands, and then only follow through on the attack if the demands are not met; they won't be, but it will be seen as a consequence of the US government having a non-appeasement policy, and a post-announcement to the effect that the actions were "regrettable, but necessary" would tent to weigh heavily on regime change in the US - #1 - with the caveat that we worked out how to do that more or less peacefully every 4 years anyway over 200 years ago. It would also weigh somewhat less heavily on #2, since a general public, informed of the dangers and consequences of the then-current US foreign policy would then be in a position to put electoral pressure on their elected public officials. We might even see something as counterproductive as a "Peace Party" dedicated to US isolationism to avoid future incidents.
Either way, missing 3 months of 50% of the RAM production from Hynix from this FAB is going to hurt us. It is not just a case of the price going up due to diminished supply: lack of supply will impact production of devices using that RAM, and the inability to get supply because it's grabbed up by people with more margin to shrink out will leave some manufacturers with no RAM.
If you were to hypothetically project a 3 month supply gap window on, for example, all Intel mobile processors, as a result of a simultaneous attack on a, relatively speaking, small number of FAB targets (all that actually necessary is breaking the clean room viability; no loss of life required), you can see what that would do to economies which relied on that production not being interrupted.
Asymmetric warfare is about leverage, and Western nations foreign policies, at least these days, are about economics. So in closing, I will reiterate my initial point: this is why terrorists are stupid.
when I'm going to be paying for a carrier contract anyway
Because the math has changed recently and pre-pay is now cheaper than post-pay, unless you have some special use case. The only network where you can use your "free" 5C is on Sprint.
As of last Friday. Verizon has offered to match this, but has yet to update their pre-order website, which requires $99 or a monthly bill roll-in to cover the $99.
But yes, you are correct that the US model economics differ from the European model. The US model is to sell you a two year contract, give you a "free" phone, and then dangle a new "free" phone 6 months before the 2 year contract is up in order to get you to re-up for another 2 year contract.
This is one of the reasons none of the U.S. carriers are interested in pushing Android updates: if you get the most recent Android OS without the new phone they are dangling in front of you, what's your incentive to not go month-to-month? If the carriers have no incentive to push an update, then the device manufacturers have no incentive to even develop the update in the first place, and so you have this multitude of Android phones with a multitude of versions and a multitude of vendor specific porting changes to get it to run on the device. Hence no standard application market for Android, like the Apple App Store, and the smaller vendor markets and Google's market never get more than a fraction of the number of applications you see in the App Store.
Also US consumers are generally not pre-pay for anything: everything is about buying on credit. This goes for phones, but it also goes for mid ticket items which Europeans save up for then buy outright, like cars. Europeans grudgingly do the mortgage thing on houses.
If you are buying the iPhone outright to avoid the carrier entanglements: good for you, but in that case, unless you plan to live without Apps, iPhones are not a fungible commodity, or you'd be buying a fire sale Win8 phone from a doomed vendor, like the Nokia Lumia. So you aren't price sensitive at that point, you're just kvetching that the rest of the industry won't change its business model to suit the way you personally, as an insignificant fraction of their market, like to buy things. In fact, I would have to say that their target market doesn't include you at all, since their target market is "people who pay more than they have to when all costs are amortized and totaled because of carrier lock-in".
This is why terrorists are stupid. Damage an air conditioner, unprotected from a parachutist, on the outside of a DRAM plant = billions of dollars of economic damage.
It's still $549. That's not exactly cheap, and isn't really any different price-wise than when they simply offered the older model. Not seeing the point.
Now free with contract; still not seeing the point of dropping $549 for a phone when I'm going to be paying for a carrier contract anyway to be able to make phone calls.
Oh where do I begin to describe the skewed perspective of this article. It seems clear the author had recently read the book "The Pencil" and thought they could write up a little tidbit about it with patents. But, when you start doing the math, it really falls through. The "invention" was created in 1858. The supreme court ruling about the patent came in 1875, nearly 20 years later (so at the point where the patent would have nearly expired anyways).
It was either expired (patent term was 14 years from date of filing), or within a year of expiring (an additional filing for a 7 year extension was permitted). No info as to whether an extension was filed for this guy. This is because it fell under the purview of the Patent Act of 1836.
Well, a TOS statement that has yet to be enforced against anyone on the assumption that the customer also isn't evil is a hell of a lot less evil than an asymmetric rate for upload/download speeds or upload caps as a technical enforcement measure.
PS: Got your own ISP to lift their RIAA/MPAA imposed download cap yet?
Right, Google's problems with evil are more on the ad side. They paid extortion to the tune of $500,000,000 as a penalty to the Department of Justice to keep Larry Page out of jail when Google offended the pharmaceutical industry cartel. That amount was sufficient to match the bribes paid by the pharmaceutical industry, and since it shut down most internet pharmacies being found via google, they didn't pursue the matter further.
Actually what would be a lot more useful would be to have a process in place for the American public to pardon people it wants pardoned, and damn what the politcos want if they chose to pardon someone or a class of someones. That would act as a big check on abuse of power by people holding public office.
For example, I'd likely vote to pardon Snowden, all non-violent drug offenders, and almost everyone engaged in a consensual crime, or those currently incarcerated for a crime for which the law has since been repealed or struck down (ironically, just because you were jailed for having oral sex with your wife in Utah prior to 2003 when the law was struck down doesn't mean they let you out of jail if you had time left on your sentence).
It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon.
That's all fine-and-dandy until you need to keep track of the different version of library packages and make sure they're all up-to-date and not conflicting.
You don't need to worry about different versions because there is only one version of the library associated with the app: the one in the app bundle.
The way to make sure your app is up to date is to ensure it's up to date by dragging a new version, or having the app insert itself into the Software Update process, or to have it maintain its own update checks and cycle. The method to do this is documented.
By definition, since all libraries are private to the app, they are non-conflicting. That's the reason they are private to the app.
Do you want your system handling patches and updates or do you want to manually go through an infinite number of directories and waste your time?
I would prefer updates happen in binary form, and that the application handle itself, either by having code to do it on startup, or by installing its own handler into the Software Update process so that it gets checked when the system automatically checks for Apple supplied updates.
Basically, this boils down to you having two non-existant problems, and one self-caused problem (or vendor caused, if they don't support internal updates.
The UNIX side of OS X has been just fine in the recent releases. The problems with OS X are:
1. It doesn't have a real package management system.
It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon. If you follow the Mac model, and don't try to install your files all over from hell to breakfast, there's no issue. This is why a lot of demo machines in stores now have epoxy in their USB ports (e.g. the ones at Fry's), since people were stealing already activated copies of Microsoft Office by plugging in their iPod shuffle or other thumb-drive and just dragging it over.
If you want to install all over from hell to breakfast, there's always http://www.macports.org/ or you can make a 5 line change to the FreeBSD ports management system to use "${MAKE}" instead of "make", and deal with two "echo" compatibility issues which are fixed by using "printf" instead, and almost all of the FreeBSD ports system "just works". I gave those patches back to FreeBSD (via Jordan Hubbard); not sure if they made them in.
Note that another benefit of the Mac model is that you can have different applications requiring different versions of libraries, and nobody cares except people already short on disk space. Duplicate block coalescing can fix that, but only works for ZFS, which is an add-on.
2. Long turnaround time for security patches. They should stop this insane "we have to wait until 10.x.y until we ship this patch even though it's ready." A proper package management system would certainly help there.
This is an issue for security problems in the kernel; otherwise, Apple ships regular security patches for all user space components; leave Software Update turned on, and it's automatic, and will pop up and bug you to install updates, since they usually mean an application or system restart (depending on what layer the installs happen).
For the kernel, this is really a management/resources/security-guys-do-not-push-hard-enough problem; the current development model for the Mac OS X kernel is "Scrum", which is good if you want to keep an organ bank of coders around to throw at the next iPhone/iPod Touch/iPad problem, and less good if you actually want to make substantive changes or progress in kernel technology, so it's mostly on managements back. I agree this is a problem.
(1) Use the targeted approach to get rid of the bacteria.
(2) Immunize to provoke the Th1 response that prevents the cancer.
Leave it to a DDS to do a study saying "cavities are good, and we should not take any rash actions which would reduce the customer base for dentists, and if you do, you are all going to get cancer and die".
Not just userland. Much of the OS X kernel is derived from FreeBSD and NetBSD, too.
Almost all of the BSD in the kernel is based on BSD 4.4-Lite2 and NetBSD; there are a couple of small sections, which ironically I wrote, that were pulled in from FreeBSD, like the BSD parts of the init code, and parts that generally everyone wrote, like chunks of the networking stack. I really wanted to change some of the VM APIs to be more like FreeBSD, i.e. in band errors in value returns should have been converted to value returned into variables passed by address with out of band error returns, but this would have required work on the part of the Intel guys prior to the Intel code integration.
The problem, though, is that Apple has slowly stopped developing the Unix parts.
This is BS.
They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework.
No, that's a combination of several factors, some of them being Apple having poor representation on the UNIX steering committee. Specifically regarding the committee, there's no such thing as a pthread_atexec() and several other APIs which would be necessary in order to make fork() deterministically useful in already multithreaded programs.
The CoreFoundation factor is a combination of GCD, which starts and stops threads behind the programs back (and can't register exec handlers), and directory services, which for non-root processes starts another thread as a means of security partitioning to support everything DNS and network address related. It doesn't actually need to do this, and neither does GCD, but between that and the missing process lifecycle management functions in POSIX for threads, it's not supportable.
Basically, CoreFoundation is a piece of shit. It's now showing its initial lack of threads support in the design, and binary backward compatibility prevents it being redesigned. Catch-22.
The positive side of this is that people effectively have to use posix_spawn[p]() instead, which means they don't have to copy a massive fricking address space from one process to the other, which is expensive as hell in Mach, since they haven't adopted the red/black tree acceleration for ptov[] translations, mostly because there's too much code that relies on address aliases. In CS terms, the p:v has a cardinality of 1:N instead of 1:!, which breaks code relying on ptov(). There wasn't a lot of it, but there was absolutely no hope of getting rid of the aliases without the VM API changes I mentioned previously.
So boo fricking hoo: use LaunchServices like you were supposed to be doing when using CoreFoundation, and quit using fork() directly, and your problems will go away.
Neither are they tracking POSIX or BSD developments anymore, having stopped several years ago.
The only "tracking" of BSD kernel code that happened since 2003 that I'm aware of (but I left Apple in 2011) was in the networking code, and there was precious little of that, since Apple and BSD selected different concurrency models. BSDs is arguably more scalable, if you have unlimited memory to burn, other wise you want XNUs. You probably want XNUs anyway, particularly if you want to take cores on and offline out from under the CPU for power management or thermal budgetary reasons, and the scalability issues can be addressed.
OS X's POSIX support is a full release behind. They're compliant to the 2001 specification, but the latest is 2008, plus fixes. In a few years, their POSIX support will be about as useful as Windows', in terms of interoperability with modern FOSS.
That just asinine.
First off, the next jump to standards conformance, if any, will be unlikely to be 2008, since it's not going to be widely adopted by industry until IBM and Oracle can get their shit together, which takes more than 5 years, since it includes a migration strategy for mai
I would think it would be embarrassingly easy to find people saying stupid things on the news these days without a lot of searching, and then just comment on the stupid things you find. It's sort of analogous to looking for a needle in a needle factory.
Dave Winer basically invented application scripting on Macintosh when he released Userland Frontier in the late 1980's. This was before Apple's own AppleScript. He also was a key in the creation of XML-RPC and SOAP for creating web API's.
I read this as a HARD requirement for scriptablity across all applications. If all apps are able to respond to and make scripting API requests, any app would be able to be the "programming" language. Python, Sqeak, C, Photoshop, nginx, OpenOffice could all be equals.
That was my take, too. I recognized the name, and more or less translated the idea to "I want PhoneGap for everything".
This idea will never fly. Dave is old. I understand his perspective, because I lived through that era too: no one writes malicious code because everyone plays nice, and because of the way Apple codes things I don't have libraries to e.g. access my iTunes library as an iTunes library without doing a whole hell of a lot of work so I'd like to be able to ask iTunes to do it for me.
The reason this will never fly is manifold:
- There are incredibly sound UI and UX reasons to not allow "skinning" or "themes", or, frankly, even things like the Facebook ban on "Social Fixer". Programmers who like to tweak UI bits, but who either could never write iTunes on their own, or find doing things like that incredibly boring, don't like the lack of tweakability. Users, on the other hand, like to be able to call up a support person and get quick answers to their problems. Having the same icons and application layout everywhere GREATLY helps this. Users also do not like learning curves; having the same "look and feel", and having all applications follow the same HI guidelines, like they all have a "File" menu in the same place, and they all largely have the same items on the menus in the same places GREATLY helps this. It also makes it look like all your Mac apps were written in Cupertino, and all your Windows apps were written in Redmond, which programmers also hate, since it disallows use of trade dress to make their product stand out from the other products that do almost exactly the same thing.
- It requires reaching across NECESSARY security protection domains. If I can talk to iTunes, and make it do things, there is effectively no more protection domain between myself and iTunes. Same for AddressBook. Same for Email. Same for Safari. Same for GPS info. Same for making phone calls. Make no mistake: there are assholes out there writing code; some do it just to be assholes, while others do it for money, politics, religion, etc.. But there are assholes, and having these Chinese walls between things that operate on data keeps a nice apps data from being accessed by assholes. So no cross-compaartmentalized scripting, unless you want to let the assholes do it too.
- There just aren't that many programmers out there, and of those, only a fraction really get their rocks off tweaking UIs, and of those, only a fraction like to do their tweaking in a scripting rather than a compiled language. So there's not a lot of MARKET for the idea, and without a market, the idea isn't going to get done. Or it'll get done, and go nowhere, because the company will fail... hence my earlier comment about him feeling free to found a company or three to pursue the idea.
Really he should be asking for APIs for things, but that's very antithetical to the whole historical Apple worldview that "iTunes databases should be managed by iTunes, and everyone else should keep their damn noses out". That's a pretty big paradigm shift for Dave, and an even bigger one for Apple: it's just not going to happen.
Most everyone else will also be reluctant to open up APIs to their data, even under Android, even under the misdirection of calling it "making things scriptable". Welcome to the reason that CORBA and OmniORB and other object request broker paradigms are niche market at best and curiousities at worst.
Slashdot Mirror
With health care costs and benefits, doesn't it cost MORE to hire a full time worker than two part time workers?
We are talking about making 20 the new "full time", which would mean that your point doesn't apply.
But yes, this is one of the problems with the current Affordable Care Act unfunded mandates, as opposed to going to a single payer system, like the national health services in most of the rest of the world. The consequence of which, of course, is that AIG would have missed out on their TARP-style bailout for having everyone forced to purchase insurance from one of their member companies. Might have damaged someone's campaign contributions.
But in fact it's NOT properly supported.
If you read the wiki that the article poster linked to, there are all sorts of caveats and missing functionality. "Properly Supported" means functional parity, and from where it sits right now, there is not functional parity.
What's the advantage to making a cheap device which people would buy to use as a display instead of a means of reading books purchased from B&N? I think they are also unlikely to build ones that can be used as BBQ grills.
As long as the device is sold at a small profit, or at minimum not at a loss, it's worth it to sell them to increase the distributed base. If you have the device for one purpose, you might use it for another. Plus, you get to claim the sales as... sales. It gets your volume up, so you can buy components at lower prices...
Unless it's a loss-leader for content sales for the device, or the additional sales drive costs down through economies of scale, you are WRONG: it is NOT worth it to sell them at a loss, even a small one.
If it's sold at a small profit, as in the device manufacturing process is self sustaining, then yes, it's probably worthwhile. But realize that self-sustaining in this regard includes amortized R&D costs, production tooling costs, manufacturing costs, shipping costs, and flooring costs for putting the devices inside the front door and having Nook sales areas inside physical B&N stores where you would otherwise have more books, a wider variety of titles, and other things which also compete for flooring, such as book bags, book lights, and so on. As a general rule, this COGS - Cost Of Goods Sold - will be twice the total of the parts costs and manufacturing costs to get the device into shrink-wrapped boxes.
My understanding is that Nooks are sold as a loss-leader in the expectation of future book sales. My undestanding comes from their 10Q and EDGAR filings with the US government, which are a matter of public record.
The whole "Internet bubble 1.0" dotbomb was about the non-viability of "sell at a loss, make it up in volume" business model. That business model was about capturing the market to the exclusion of competitors, and then raising prices, after which people will remain your customers out of early loyalty, or out of lack of choice in the matter.
The chinese restaurant "revolving door" in the small industrial park near my home is predicated on the same business model, and the reason I call it a "revolving door" is that the business model doesn't work. You get one restaurant in ant really low prices, then they establish a lunch crowd based on price, and then another restaurant opens in the park and undercuts the price, the first goes out of business, and the cycle repeats. These restaurants run on cash flow, or at a loss based on an initial investment which gets eaten up. The people in the park could care less, so long as they have a place to go for chinese food for lunch, and during the rare times there is no restaurant, they drive to the chinese place by the post office instead, and pay a higher price which is capable of sustaining the business there.
Personally, I would never sell a multifunction device where I'm not getting income from each function; it just doesn't make sense. That's why if you want to read .DOC files or .PDFs, it costs you for the extra software on the Nook, since if you are reading either of those, you aren't reading content purchased from B&N. The only way an unrestricted universal content reader makes sense is if it's sold at an at least 6% premium above COGS, and so far parts cost have kept that out of reach (this answers another question posed early on in the posts on this topic).
Consider a worker who could build 10 widgets a year and afford to buy 5 widgets back in "the old days." With improvements in technology, now a worker can build 50 widgets a year --- and gets paid enough to buy 4, because they're competing for jobs with all the other workers laid off who now can afford to buy 0.
Why didn't some of the laid off workers start 4 more businesses to soak up the additional productivity? Clearly, any worker they could hire would be 5 times more productive than before the change over, so now they can afford to start their won businesses and employ people, right?
I think you nailed it. The 8 hour workday needs to be shortened.
This might be workable... ...if you were able to make it so that it cost a company exactly the same to hire 2 workers @ 20 hours/week as it costs them to hire 1 worker @ 40 hours/week. Which means the government eats the individual per employee costs for the extra employees, as taxes which they do not collect.
Finally a device with a color e-ink display, pretty please? How about making it work as a computer display, too?
What's the advantage to making a cheap device which people would buy to use as a display instead of a means of reading books purchased from B&N? I think they are also unlikely to build ones that can be used as BBQ grills.
This is why terrorists are stupid. Damage an air conditioner, unprotected from a parachutist, on the outside of a DRAM plant = billions of dollars of economic damage.
How many candlelit vigils have have you seen organized for the loss of DRAM factory?
Now how many were there for the Boston bombings?
Terrorists aren't so stupid.
How many candlelit vigils does it take to result in a substantial change in US foreign policy, or the instrumentality used to implement said policy?
So how effective were those attacks, again? What substantive, measurable progress towards their goals was achieved? Are we even generally aware of the goals of the attack? If not, how can the US electorate impact the policy decisions of their elected officials in such a way as to preclude future attacks?
To be totally direct and unequivocal, those attacks were totally ineffective at achieving anything but lost work days and candle sales, which were unlikely the terrorists goals which motivated the attacks in the first place.
You're assuming that the objective of terrorism is to cause generalised harm. If that was the goal it'd be even easier for them to just stay at home and punch each other in the face.
A man can dream.
Anyway, to complete the thought: terrorism is about retribution, and about conveying a political message. Those actions have specific targets, and raising the price of memory does not necessarily affect those targets to the extent or with the specificity demanded.
Terrorism is a form of asymmetric warfare. All warfare is waged with a goal of defeating or disabling or stalling the enemy; whether you measure this as "toppling their government", "evidencing a strong threat of retribution for political intervention in a region/country not their own", or "causing the enemy to engage in domestic expenditures of resources and/or to engage in policies objectionable to its citizenry as a means of causing them to disengage from external matters" is irrelevant.
The 9/11 attacks were more or less effective at the third of those. They might have been effective at the second of these as a target goal as well, but the US general population is blithely unaware of the activities the US government takes in implementation of its foreign policy, if they are even aware of US foreign policy at all. This is manifestly evident in the US public perception of the Snowden revelations. Clearly, the government became aware fairly quickly of the perpetrators, and were they persuadable on #2 at all, they were (apparently) not persuaded. Quite the opposite.
Perhaps the next set of terrorists will take that lesson to heart, and make an announcement prior to an attack regarding their demands, and then only follow through on the attack if the demands are not met; they won't be, but it will be seen as a consequence of the US government having a non-appeasement policy, and a post-announcement to the effect that the actions were "regrettable, but necessary" would tent to weigh heavily on regime change in the US - #1 - with the caveat that we worked out how to do that more or less peacefully every 4 years anyway over 200 years ago. It would also weigh somewhat less heavily on #2, since a general public, informed of the dangers and consequences of the then-current US foreign policy would then be in a position to put electoral pressure on their elected public officials. We might even see something as counterproductive as a "Peace Party" dedicated to US isolationism to avoid future incidents.
Either way, missing 3 months of 50% of the RAM production from Hynix from this FAB is going to hurt us. It is not just a case of the price going up due to diminished supply: lack of supply will impact production of devices using that RAM, and the inability to get supply because it's grabbed up by people with more margin to shrink out will leave some manufacturers with no RAM.
If you were to hypothetically project a 3 month supply gap window on, for example, all Intel mobile processors, as a result of a simultaneous attack on a, relatively speaking, small number of FAB targets (all that actually necessary is breaking the clean room viability; no loss of life required), you can see what that would do to economies which relied on that production not being interrupted.
Asymmetric warfare is about leverage, and Western nations foreign policies, at least these days, are about economics. So in closing, I will reiterate my initial point: this is why terrorists are stupid.
when I'm going to be paying for a carrier contract anyway
Because the math has changed recently and pre-pay is now cheaper than post-pay, unless you have some special use case. The only network where you can use your "free" 5C is on Sprint.
Wrong;
AT&T: http://www.att.com/wireless/iphone/#fbid=Z0dbgc1cUkn
T-Mobile: http://www.tmonews.com/2013/09/t-mobile-stores-to-open-at-8am-local-time-friday-for-iphone-5s5c-launch/
As of last Friday. Verizon has offered to match this, but has yet to update their pre-order website, which requires $99 or a monthly bill roll-in to cover the $99.
But yes, you are correct that the US model economics differ from the European model. The US model is to sell you a two year contract, give you a "free" phone, and then dangle a new "free" phone 6 months before the 2 year contract is up in order to get you to re-up for another 2 year contract.
This is one of the reasons none of the U.S. carriers are interested in pushing Android updates: if you get the most recent Android OS without the new phone they are dangling in front of you, what's your incentive to not go month-to-month? If the carriers have no incentive to push an update, then the device manufacturers have no incentive to even develop the update in the first place, and so you have this multitude of Android phones with a multitude of versions and a multitude of vendor specific porting changes to get it to run on the device. Hence no standard application market for Android, like the Apple App Store, and the smaller vendor markets and Google's market never get more than a fraction of the number of applications you see in the App Store.
Also US consumers are generally not pre-pay for anything: everything is about buying on credit. This goes for phones, but it also goes for mid ticket items which Europeans save up for then buy outright, like cars. Europeans grudgingly do the mortgage thing on houses.
If you are buying the iPhone outright to avoid the carrier entanglements: good for you, but in that case, unless you plan to live without Apps, iPhones are not a fungible commodity, or you'd be buying a fire sale Win8 phone from a doomed vendor, like the Nokia Lumia. So you aren't price sensitive at that point, you're just kvetching that the rest of the industry won't change its business model to suit the way you personally, as an insignificant fraction of their market, like to buy things. In fact, I would have to say that their target market doesn't include you at all, since their target market is "people who pay more than they have to when all costs are amortized and totaled because of carrier lock-in".
This is why terrorists are stupid. Damage an air conditioner, unprotected from a parachutist, on the outside of a DRAM plant = billions of dollars of economic damage.
Sure. What's your noun to define, in general, a remote controlled unmanned vehicle?
We'll start a campaign to have your word replace "drone" in the Oxford English, Merriam Webster, Collins dictionaries immediately.
ROV
The taxonomy isn't actually that difficult to understand:
Drone (Unmanned vehicle)
ROV (Remotely Operated Vehicle)
RPV (Remotely Piloted Vehicle)
UAV (Unmanned Ariel Vehicle)
AV (Autonomous Vehicle)
Technically, these things are Drones, but that's about the least specific thing you could call them.
It's still $549. That's not exactly cheap, and isn't really any different price-wise than when they simply offered the older model. Not seeing the point.
Now free with contract; still not seeing the point of dropping $549 for a phone when I'm going to be paying for a carrier contract anyway to be able to make phone calls.
Oh where do I begin to describe the skewed perspective of this article. It seems clear the author had recently read the book "The Pencil" and thought they could write up a little tidbit about it with patents. But, when you start doing the math, it really falls through. The "invention" was created in 1858. The supreme court ruling about the patent came in 1875, nearly 20 years later (so at the point where the patent would have nearly expired anyways).
It was either expired (patent term was 14 years from date of filing), or within a year of expiring (an additional filing for a 7 year extension was permitted). No info as to whether an extension was filed for this guy. This is because it fell under the purview of the Patent Act of 1836.
Ironically, during the 1890 depression, and again during the great depression, people in general held a dim view of patents, as they more or less do today, so by that measure, are we in a depression?
http://en.wikipedia.org/wiki/History_of_United_States_patent_law#The_Sherman_Antitrust_Act
Makes you wonder a bit...
So evil is ok as long as it's reasonable?
Well, a TOS statement that has yet to be enforced against anyone on the assumption that the customer also isn't evil is a hell of a lot less evil than an asymmetric rate for upload/download speeds or upload caps as a technical enforcement measure.
PS: Got your own ISP to lift their RIAA/MPAA imposed download cap yet?
Right, Google's problems with evil are more on the ad side. They paid extortion to the tune of $500,000,000 as a penalty to the Department of Justice to keep Larry Page out of jail when Google offended the pharmaceutical industry cartel. That amount was sufficient to match the bribes paid by the pharmaceutical industry, and since it shut down most internet pharmacies being found via google, they didn't pursue the matter further.
There, fixed that for ya.
So these guys, but 3 years late to the party?
http://www.cleancookstoves.org/
I guess mechanical and chemical engineering masters students all need a thesis subject...
Actually what would be a lot more useful would be to have a process in place for the American public to pardon people it wants pardoned, and damn what the politcos want if they chose to pardon someone or a class of someones. That would act as a big check on abuse of power by people holding public office.
For example, I'd likely vote to pardon Snowden, all non-violent drug offenders, and almost everyone engaged in a consensual crime, or those currently incarcerated for a crime for which the law has since been repealed or struck down (ironically, just because you were jailed for having oral sex with your wife in Utah prior to 2003 when the law was struck down doesn't mean they let you out of jail if you had time left on your sentence).
Edward Snowden is like Santa Claus! He know whether you've been good or bad, and the presents just keep coming like clockwork!
It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon.
That's all fine-and-dandy until you need to keep track of the different version of library packages and make sure they're all up-to-date and not conflicting.
You don't need to worry about different versions because there is only one version of the library associated with the app: the one in the app bundle.
The way to make sure your app is up to date is to ensure it's up to date by dragging a new version, or having the app insert itself into the Software Update process, or to have it maintain its own update checks and cycle. The method to do this is documented.
By definition, since all libraries are private to the app, they are non-conflicting. That's the reason they are private to the app.
Do you want your system handling patches and updates or do you want to manually go through an infinite number of directories and waste your time?
I would prefer updates happen in binary form, and that the application handle itself, either by having code to do it on startup, or by installing its own handler into the Software Update process so that it gets checked when the system automatically checks for Apple supplied updates.
Basically, this boils down to you having two non-existant problems, and one self-caused problem (or vendor caused, if they don't support internal updates.
The UNIX side of OS X has been just fine in the recent releases. The problems with OS X are:
1. It doesn't have a real package management system.
It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon. If you follow the Mac model, and don't try to install your files all over from hell to breakfast, there's no issue. This is why a lot of demo machines in stores now have epoxy in their USB ports (e.g. the ones at Fry's), since people were stealing already activated copies of Microsoft Office by plugging in their iPod shuffle or other thumb-drive and just dragging it over.
If you want to install all over from hell to breakfast, there's always http://www.macports.org/ or you can make a 5 line change to the FreeBSD ports management system to use "${MAKE}" instead of "make", and deal with two "echo" compatibility issues which are fixed by using "printf" instead, and almost all of the FreeBSD ports system "just works". I gave those patches back to FreeBSD (via Jordan Hubbard); not sure if they made them in.
Note that another benefit of the Mac model is that you can have different applications requiring different versions of libraries, and nobody cares except people already short on disk space. Duplicate block coalescing can fix that, but only works for ZFS, which is an add-on.
2. Long turnaround time for security patches. They should stop this insane "we have to wait until 10.x.y until we ship this patch even though it's ready." A proper package management system would certainly help there.
This is an issue for security problems in the kernel; otherwise, Apple ships regular security patches for all user space components; leave Software Update turned on, and it's automatic, and will pop up and bug you to install updates, since they usually mean an application or system restart (depending on what layer the installs happen).
For the kernel, this is really a management/resources/security-guys-do-not-push-hard-enough problem; the current development model for the Mac OS X kernel is "Scrum", which is good if you want to keep an organ bank of coders around to throw at the next iPhone/iPod Touch/iPad problem, and less good if you actually want to make substantive changes or progress in kernel technology, so it's mostly on managements back. I agree this is a problem.
Fine, take them at their word.
(1) Use the targeted approach to get rid of the bacteria.
(2) Immunize to provoke the Th1 response that prevents the cancer.
Leave it to a DDS to do a study saying "cavities are good, and we should not take any rash actions which would reduce the customer base for dentists, and if you do, you are all going to get cancer and die".
Not just userland. Much of the OS X kernel is derived from FreeBSD and NetBSD, too.
Almost all of the BSD in the kernel is based on BSD 4.4-Lite2 and NetBSD; there are a couple of small sections, which ironically I wrote, that were pulled in from FreeBSD, like the BSD parts of the init code, and parts that generally everyone wrote, like chunks of the networking stack. I really wanted to change some of the VM APIs to be more like FreeBSD, i.e. in band errors in value returns should have been converted to value returned into variables passed by address with out of band error returns, but this would have required work on the part of the Intel guys prior to the Intel code integration.
The problem, though, is that Apple has slowly stopped developing the Unix parts.
This is BS.
They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework.
No, that's a combination of several factors, some of them being Apple having poor representation on the UNIX steering committee. Specifically regarding the committee, there's no such thing as a pthread_atexec() and several other APIs which would be necessary in order to make fork() deterministically useful in already multithreaded programs.
The CoreFoundation factor is a combination of GCD, which starts and stops threads behind the programs back (and can't register exec handlers), and directory services, which for non-root processes starts another thread as a means of security partitioning to support everything DNS and network address related. It doesn't actually need to do this, and neither does GCD, but between that and the missing process lifecycle management functions in POSIX for threads, it's not supportable.
Basically, CoreFoundation is a piece of shit. It's now showing its initial lack of threads support in the design, and binary backward compatibility prevents it being redesigned. Catch-22.
The positive side of this is that people effectively have to use posix_spawn[p]() instead, which means they don't have to copy a massive fricking address space from one process to the other, which is expensive as hell in Mach, since they haven't adopted the red/black tree acceleration for ptov[] translations, mostly because there's too much code that relies on address aliases. In CS terms, the p:v has a cardinality of 1:N instead of 1:!, which breaks code relying on ptov(). There wasn't a lot of it, but there was absolutely no hope of getting rid of the aliases without the VM API changes I mentioned previously.
So boo fricking hoo: use LaunchServices like you were supposed to be doing when using CoreFoundation, and quit using fork() directly, and your problems will go away.
Neither are they tracking POSIX or BSD developments anymore, having stopped several years ago.
The only "tracking" of BSD kernel code that happened since 2003 that I'm aware of (but I left Apple in 2011) was in the networking code, and there was precious little of that, since Apple and BSD selected different concurrency models. BSDs is arguably more scalable, if you have unlimited memory to burn, other wise you want XNUs. You probably want XNUs anyway, particularly if you want to take cores on and offline out from under the CPU for power management or thermal budgetary reasons, and the scalability issues can be addressed.
OS X's POSIX support is a full release behind. They're compliant to the 2001 specification, but the latest is 2008, plus fixes. In a few years, their POSIX support will be about as useful as Windows', in terms of interoperability with modern FOSS.
That just asinine.
First off, the next jump to standards conformance, if any, will be unlikely to be 2008, since it's not going to be widely adopted by industry until IBM and Oracle can get their shit together, which takes more than 5 years, since it includes a migration strategy for mai
Not precisely. He doesn't think of himself as the only user.
Well, he's (effectively) wrong on that count.
SourceForge is indicating a total of 35 downloads, and I'd bet at least a couple of them were the result of this Slashdot article.
Does it really take that level of infrastructure?
I would think it would be embarrassingly easy to find people saying stupid things on the news these days without a lot of searching, and then just comment on the stupid things you find. It's sort of analogous to looking for a needle in a needle factory.
Dave Winer basically invented application scripting on Macintosh when he released Userland Frontier in the late 1980's. This was before Apple's own AppleScript. He also was a key in the creation of XML-RPC and SOAP for creating web API's.
I read this as a HARD requirement for scriptablity across all applications. If all apps are able to respond to and make scripting API requests, any app would be able to be the "programming" language. Python, Sqeak, C, Photoshop, nginx, OpenOffice could all be equals.
That was my take, too. I recognized the name, and more or less translated the idea to "I want PhoneGap for everything".
This idea will never fly. Dave is old. I understand his perspective, because I lived through that era too: no one writes malicious code because everyone plays nice, and because of the way Apple codes things I don't have libraries to e.g. access my iTunes library as an iTunes library without doing a whole hell of a lot of work so I'd like to be able to ask iTunes to do it for me.
The reason this will never fly is manifold:
- There are incredibly sound UI and UX reasons to not allow "skinning" or "themes", or, frankly, even things like the Facebook ban on "Social Fixer". Programmers who like to tweak UI bits, but who either could never write iTunes on their own, or find doing things like that incredibly boring, don't like the lack of tweakability. Users, on the other hand, like to be able to call up a support person and get quick answers to their problems. Having the same icons and application layout everywhere GREATLY helps this. Users also do not like learning curves; having the same "look and feel", and having all applications follow the same HI guidelines, like they all have a "File" menu in the same place, and they all largely have the same items on the menus in the same places GREATLY helps this. It also makes it look like all your Mac apps were written in Cupertino, and all your Windows apps were written in Redmond, which programmers also hate, since it disallows use of trade dress to make their product stand out from the other products that do almost exactly the same thing.
- It requires reaching across NECESSARY security protection domains. If I can talk to iTunes, and make it do things, there is effectively no more protection domain between myself and iTunes. Same for AddressBook. Same for Email. Same for Safari. Same for GPS info. Same for making phone calls. Make no mistake: there are assholes out there writing code; some do it just to be assholes, while others do it for money, politics, religion, etc.. But there are assholes, and having these Chinese walls between things that operate on data keeps a nice apps data from being accessed by assholes. So no cross-compaartmentalized scripting, unless you want to let the assholes do it too.
- There just aren't that many programmers out there, and of those, only a fraction really get their rocks off tweaking UIs, and of those, only a fraction like to do their tweaking in a scripting rather than a compiled language. So there's not a lot of MARKET for the idea, and without a market, the idea isn't going to get done. Or it'll get done, and go nowhere, because the company will fail... hence my earlier comment about him feeling free to found a company or three to pursue the idea.
Really he should be asking for APIs for things, but that's very antithetical to the whole historical Apple worldview that "iTunes databases should be managed by iTunes, and everyone else should keep their damn noses out". That's a pretty big paradigm shift for Dave, and an even bigger one for Apple: it's just not going to happen.
Most everyone else will also be reluctant to open up APIs to their data, even under Android, even under the misdirection of calling it "making things scriptable". Welcome to the reason that CORBA and OmniORB and other object request broker paradigms are niche market at best and curiousities at worst.