If your kids happen to make money, parents control that money until they are 18. They should also suffer the liability as well.
You can't have one without the other. Either children are responsible or they are not.
You have it wrong.
The page was created on a school computer while the school was acting in loco parentis for the child. If anyone should be held responsible *instead of the child, whose fault it is*, it would be the school, with "contribution to the delinquency of a minor" by the "friend" who helped them create the page.
At worst, the parents are guilty of "contributory negligence" for not being software engineers.
10.5 ran on Intel. Making Classic run, but only if you were using PPC hardware, was not an option, due to the large amount of kernel and interface changes necessary to support Intel.
Back up for a moment though, and you're recall that 10.4 supported Intel, which I believe would mean that those changes had already been made, wouldn't it? The way you guys avoided having to do a rewrite of Classic was by maintaining separate builds for PPC and Intel Macs during Tiger's run, with the PPC builds featuring Classic support and the Intel builds lacking it. Couldn't that pattern have been carried forward into 10.5, given that PPC hardware was not long for the world anyway? Instead, Apple merged the builds in 10.5 (which only lasted for that one version), which necessitated dropping Classic for the reasons you said.
The 10.4 Intel builds were "a" versions. The intent was always to integrate them, but they were run as a separate "build train". This is the same way that development versions are handled, and it was the same way that Mac OS X Server versions used to be handled.
To carry it along, it was necessary to build and designate an entire "build fleet" - systems in a server room used to do the builds - and to staff build engineers, and integration engineers, and duplicate roles between Intel and PPC development, etc.. So there was a significant cost associated with it, including that things were not being "built fat". This meant that if you made a change in the PPC code that happened to break the Intel build, since you personally didn't have an Intel system, to do the test builds on, let alone try to run the code to make sure it still worked, someone had to clean it up for you so that it worked on both Intel and PPC. It was incredibly burdensome, and it meant that those people, who were bright people, were stuck working on that, rather than the next great thing.
Technically, it could have been done, but it didn't make economic sense, and it didn't make resource sense (at the time, in Silicon Valley, the feeling was that Google was hiring all available talent so nobody else could hire them, regardless of whether or not Google actually had anything useful for them to do with their time or not).
I'd agree that it was an economic decision, as part of getting people to stop buying PPCs, and to stop waiting on buying Intel, when a purchase was going to happen, but there was still a choice of one or the other. But it was also a resource and process overhead problem.
If Intel support for Classic was the issue, then why not ditch Classic after 10.5, instead of 10.4? After all, PowerPCs were still supported for 10.5, so Classic could have been kept around without needing to port it to Intel.
10.5 ran on Intel. Making Classic run, but only if you were using PPC hardware, was not an option, due to the large amount of kernel and interface changes necessary to support Intel. It would have basically required a complete rewrite of Classic. At the time there were just two people supporting Class vs. changes to the main OS (Alex Rosenberg and one other person), it would have require dedicating a team of people to work under them in a non-protected mode environment in order to do the work.
Most of the original Classic team had either already escaped to the iPod division, to avoid having to learn how to deal with the "inconvenience" of memory protection (think "thePort"), or they'd buckled down, and learned to live with protected mode restrictions, or they had left Apple for other companies (Adobe, etc.).
It would have required a lot of hiring to deal with the amount of change that Intel brought to all of the Mach interfaces and other parts of Mac OS X, and frankly, it would have taught them bad/obsolete programming habits, and provided little value to the company, while at the same time making the trade-off between the Intel and PPC value propositions in the wrong direction, when both types of systems were still for sale. This would have not only caused new PPC sales to cannibalize Intel sales, it would have also stretched out the support timeline for the PPC another 2 years.
All in all it would have sucked, a lot, from many perspectives.
Not trolling, just a serious question: why can I compile any software from early 90's to today on any Linux distro I've attempted without issue? It sounds like I shouldn't be able to, but it takes less than 20 minutes of finagling to compile ancient POVray software from the 90's on literally any current Linux distro.
Technically, you can't. A lot of people were still using pre-ANSI C compilers in the early 1990's, so the code will be K&R C rather than ANSI C.
Any software that uses a function name or variable that uses what's now a keyword in C89 or later won't compile correctly, it'll barf. Try naming a function "void" or "restrict" or "const" or "volatile" or typdef'ing something named "_bool". Likewise, you should try compiling most of the contents of the comp.unix.sources archive, and noting the fact that -std=c89 requires ANSI C constructs, rather than K&R C constructs.
Global variables may be caches in registers in later compilers, while depending on changing a value from another thread of control (either a thread, or from a signal handler, etc.), where changing the backing value won't modify the register contents because the contents are not re-fetched on reference... i.e. compiling with a compiler that depends on the "volatile" keyword for the validity of its optimization assumptions (technically compiler writers could have introduced a "nonvolatile" keyword instead, but didn't because they wanted to lazily make the assumption and have the programmer correct it, rather than being conservative about their assumptions).
I expect that you will also see a lot of "cast discards qualifier", "comparison si always true" and similar warnings that would be errors, should you enable -Werror.
Additionally, you're going to find incompatibilities in the use of pty's, and in the use of trmio vs. termios, and other SVR4-ism's vs. BSD-isms (example: do system calls automatically restart after a signal handler fires, or do they terminate the function call with EINTR?). You will also find threads differences (such as PTHREADS_MUTEX_INITIALIZER) which will bear on your ability or inability to declare an initialized pthread_mutex_t, or need to call pthread_mutex_init(). You'll also find that OOB signalling on TCP/IP sockets behaves differently on BSD 4.2g based TCP implementation - and the code that expect a 4.2g sockets implementation - vs. later 4.3 sockets interfaces. For SVR3 and SVR4.0.2 code through 1994, you'll also see portability problems with ntoa vs. the libTLI interfaces, which lost out to the BSD interfaces for socket and host name lookup.
If you are using setuid/seteuid/etc., you will also find that older code assumes the non-existance of POSIX saved IDs - in other words, it believe that you can flip back and forth easily. Not only will this not work without jumping through an additional hoop, you're going to have security holes if you were to "fix" the system call interfaces to behave in the old way.
What you actually mean is that you haven't *noticed* any problems, in doing a not very exhaustive survey of older software. If you tried to use an older gcc that supported the K&R C dialect as a -std= argument, you'd find that the system header files with ANSI C prototypes wouldn't compile correctly.
That is not possible on Mac OSX (I've tried repeatedly, even with homebrew).
I would like to agree with you, maybe I don't understand what the problem truly is, but there is definitely a difference between compiling software for Linux vs Mac OSX. As in, one is so easy a talented kindergartener can do it, while the other is literally impossible without rewriting Mac OSX. Why is that?
Are you only trying to use POSIX interfaces on Mac OS X, or are you trying to use additional libraries supplied by the OS historically, but not supplied by the current OS version? If the answer is the latter, then the problem is that your software isn't portable, because it doesn't engage in minimal use of
"Hey, how come this new version of Mac OS doesn't work with any of my old Mac OS 9 software?", said Mac users in response to Classic support being dropped with the release of Mac OS X 10.5.
Because Apple was unwilling to port the Classic 68K emulator to Intel because of the difference in processor byte order, among other things, making such a port not worthwhile in terms of performance of the Classic software. The user experience would have been crap, and so the decision was made by upper management to not support Classic going forward on Intel.
For the PPC versions of Classic, they could have been supported under Rosetta, but it would have meant an approximate doubling of the number of APIs that were dragged forward onto Intel, for the dubious benefit of "Some Classic software will run, and some won't; sorry the stuff you personally care about doesn't".
"Hey, how come this new version of OS X doesn't work with any of my old PowerPC software?", said Mac users in response to Rosetta being dropped with the release of OS X 10.7.
This one was more related to the lack of a willingness to "freeze-dry" old versions of the libraries. The Mac OS X B&I ("Build and Integration") process required building from scratch the libraries, when building them fat, even though this was a process decision, rather than a technical one.
Effectively, it's not practically possible within the Apple process to reproduce a binary build that's identical to a previous binary build. This is because Mac OS X builds are hosted on a system where the builds depend on being incrementally built into the host environment, rather than actually cross-built to the target. What this means is that the "build from scratch" process to produce the PPC portion of the fat binaries for all the system libraries couldn't be pegged at a particular Mac OS X version, while moving forward with the Intel portion of the binaries, and therefore it was not possible to maintain binary backward compatibility - which was what both Rosetta, and before it, Classic, existed to do.
Debian Linux has this same problem when you build in a chroot to avoid "polluting" the host build environment. It's one of the reasons a build chroot is used by Linaro to support ARM architecture builds on Intel, and that's the same reason that ChromeOS for x86 is built in a chroot environment on a debian variant maintained internally for desktops at Google, rather than being simply directly cross-built into a directory tree hierarchy.
Unlike FreeBSD, neither Linux nor Mac OS X is capable of targeted cross-builds, without pollution of the build/host environment, and without using build products as part of the build.
So technically, the answer for both Linux and Mac OS X is the same: poor build environment engineering - "Worse is Better", exactly what the original article talks about - infects both operating systems.
Germany had the last laugh... German has always been "one space after terminal punctuation in sentences", and since 2009 or so, that's been retcon'ed into English as well: "Ha! Take that English speakers! You may have won the world wars, but *WE* took the second space after your periods!".
It's true that they kill birds. But so do cars and skyscrapers. And I'd wager that coal - between the waste disposal, emitted mercury, and mining - kills birds, too.
OK, as long as they *selectively* kill birds.
I mean, if all they killed were pigeons, that'd be fine, right? We might even build more of them, even without the subsidies...
What is this difficulty? When a new iOS version is released the ability to get it isn't dependent on carrier certification.
Yes, it's dependent on carrier certification if there is a new version of the baseband software that runs the Software Defined Radio. A lot of Android phones run the baseband on the same CPU as the rest of the smart Phone; Apple phones have a separate processor for the baseband, so it's not an issue for Apple, but if, for example, you are running a Qualcomm Snapdragon processor, the baseband typically runs in a separate hypervisor.
As of the Qualcomm Snapdragon S4, the architecture has changes to run as aSMP, so this is less of a problem, but it still requires certification of the baseband, if there's a baseband update as part of the BOM update. Many so-called smart phones, however, are still running the baseband on a partition of the application processor - meaning you certify with the carriers.
Carrier certification in general is a PITA, because you have to do it separately with each carrier that maintains its own communications infrastructure (meaning that as long as you certify on all the carriers which are selling services to a given VNO, you can get the VNO certification for free, but you have to do it on *ALL* the carriers they use. So it's also a separate step for each country, as well.
Also, you should be aware from the rest of my posting that carriers have absolutely zero interest in you obtaining the most recent version of Android so that you can run out your contract with the most recent version, instead of having to re-up your contract, and get a new phone to get a more recent version of Android. In addition, a lot of the productization changes, including any last minute device support improvements, and so on, are not given back to Google for future use - meaning that it's effectively a new port of Android to the platform, to get an updated version.
But there's no such excuse for Google. They've got lots of money, lots of talent, and they even have a much better ChromeOS alternative: Android.
ChromeOS: A better Android.
Android has never really been productized by Google. ChromeOS has been; it's a finished product, unlike Android.
One of the major problems with Android is that companies shipping products based on it do not pre-announce. The upshot of that fact is that you end up with every Android version being a snapshot of the Android development tree, which carries the same version numbers/names as other Android products from other vendors, but which have incompatibilities. The one saving grace is that the devices are *mostly* running Dalvik, which is *mostly* binary compatible between the same major version of Android, when *mostly* the vendor partner didn't happen to stub its toes on a major library change for an important and commonly used library.
What drives this incompatibility is not only that the Android running hardware is not specified uniformly in terms of capability, screen resolution, input methods, and so on - ChromeBooks *are*, BTW, and so are Apple devices, for the most part - but the business model for the cell phone industry actively discourages manufacturers from pursuing upgraded versions of the OS on existing cell phone hardware. Because it doesn't sell more cell phone hardware, and it doesn't sell more cell phone contracts, and there's no real App ecosystem like there is in the Apple world.
So upgrades are a net negative to the manufacturers, like Samsung, who wants to sell widgets, and they're a net negative to AT&T and Verizon, etc., who want you to have a reason to want new hardware in order to get the new version of Android so that can catch you up in a new contract for the next 18 months until the next widget comes out. And while Google would like everyone to update the OS whenever Google releases a new version, the company rivalry between the licensees will keep their development from ever being open enough that Google will be able to control the productization to the point of being able to drive an App marketplace on the order of the iTunes App store, because they aren't building it themselves. So there's no money in it to drive Google's desires to reality.
So what's point of ChromeOS? It gives Google Apple-like control over the user experience on a platform where they control the update interval and frequency, and specify the hardware closely enough that, while it's not an iPad or an iPhone, it's a close enough analog.
And that's IMO why Android was moved under the same people who ran ChromeOS, rather than the other way around, and why the Android folks are reporting to Sundar Pichai, rather than his organization reporting to Andy Rubin.
I think the hope was that Android would be able to be productized by the only other organization within Google that's been able to successfully productize a hardware product (well, I guess now there's ChromeCast, but Rishi Chandra reports into Sundar's organization, too).
Personally, I don't think this is going to work out for Android, unless there's a delay built into the version releases for supported hardware, and then given the difficulty of carrier certification and getting the specific version on, and the carriers and the widget makers get on board with the idea, which is a lot of ducks to line up in a row. Plus the carrier and manufacturer buy-in would likely come at the cost of any potential profit off an App marketplace for the first few years, unless the plan was to allow third party marketplaces (which I think would be a mistake).
So ChromeOS is a model for what Google would have liked Android to be, but failed to achieve with it.
...if you're going into a CS program. This holds in general with AP tests, don't take the ones in your intended major, because you're unlikely to get useful credit for them. This varies from school to school of course, but it's generally true.
Totally disagree. I took 5 AP classes in High School in ~1980. I was the first person in my High School to achieve this number of AP classes, and I was able to skip my freshman year of college and immediately begin taking more advanced math, physics, chemistry, honors English, and when I discovered them, CS courses. I was well on my way to multiple degrees, while most of the people I went to High School with were still deciding what to major in.
Testing out of a class is a more iffy proposition. I found that CLEP testing, at least for information learned as an autodidact, rather than in a classroom and labs, as the AP credit was, tends to give you spotty coverage of a subject, unless you are going to read the textbook for the course you intend to CLEP out of from cover to cover, and do the exercises. It also can somewhat rob you of a year in college; it's actually quite easy, by combining CLEP and AP testing, to drop your distance to a Bachelor's degree to two years. Less, if your college/university administration allows you to carry ~20 credit hours, rather than the "normal" 12-14 (admittedly, this can still be a deal, if you are there on academic scholarship, and your parents wouldn't be able to pay your tuition for you otherwise). This will generally translate to one fewer internship, and one fewer year of college social life, such as it is.
Practically speaking, I'd say that piling on the AP classes is a great way of saving money in the long term by front-loading the costs of college credit onto the state, rather than having it come out of your, or your parents, pockets, especially if you can't afford it. Assuming you apply yourself and do well on the tests, it's also exactly the thing that a college or university is going to want to see, should you apply for an academic scholarship, and between that, and a Pell Grant (now called BEOGs), it can cover your tuition, books, and living in the dorms, which is, for a poor person from a poor family, your entire opportunity for a higher education.
Why was he so inept at business - how the hell did Westinghouse screw him over?! Tesla was a genius but got screwed over by a business guy? Really? Was he THAT gullible?!
Typically, you trust the people you are working with the first one or two times, with the expectation that they will also trust you. Then your trust gets violated, and you either learn caution (e.g. "Get everything in writing"), or you continue to get screwed. If you've ever read the book "The Evolution of Cooperation" by Robert Axelrod, a perfectly logical player in the mutual security game will operate for mutual long term overall benefit, rather than short term benefit for themselves. Sadly, not everyone is entirely logical, and for many of those persons, it's not enough that they have more as a result of your mutual efforts, for them to feel good about it, *you* must have less.
No, not free. This is a scale proof of concept. Grown ups in grown up fields discuss concept,they are talking about actual design concept. Completely different then the 'concept' that you and your buddies come up with while drinking cheap beers in you pickup.
The problem was (and remains, despite vortex-based and similar proposals), "ash removal", which is to say, getting rid of the He generated as a fusion by-product to keep it from damping the fusion reaction. It was a problem with the TFTR Ttkamak in 1982, and was a problem with the NSTX, and it's a problem with this follow-on device, the spheromak (of which this article is reporting an example, dynomak).
The problem was never containment (and this dynomak, as all spheromak's, has some really clever mechanisms for containment), the problem is *still* He ash removal from the reaction plasma mixture.
So when you are ready to talk to "grown ups", leave your graduate student class projects, and address the ash removal problem, please.
Because he might want to have a decent relationship with them? Other then this issue, it might be a great product, might be getting a discount and so on.
Future relationship?!?
So they can buy *more* products with bugs an unresponsive support in the future? I can see why you'd want to protect *that* relationship...
Obviously manual controls would only work outside of restricted airspace; within restricted airspace, you'd be under the guidance of the airspace control computer.
I love the aviation consultants on this forum...
You do realize that we are no longer talking about Cessna's with Hemi's and whitewalls, we are talking about VTOL craft at this point, right? And some of us do have pilot's licenses, so we realize how ridiculous this particular vehicle is, right?
Funnily enough I think flying cars could be a better target for automation than those disastrous ground-based driverless cars.
The problem space is much more defined in the air than on the ground and, given that it's difficult for a human to look in all directions at once or judge distances of rapidly approaching objects, should probably be mandatory.
With a reserved airspace that has no manually controlled vehicles whatsoever, it's definitely a better target for automation (assuming quadrotor style manueverability). The thing that makes the ground hard is the manually controlled vehicles, the people, trash cans, road surface damage, and other mobile obstacles. Take that away, and you no longer need vision systems or any of it.
In case you don't drive much, its already too scary with cars on the ground. Can you imagine some of these idiots flying around? The horrendous crashes? Care to think about what it would be like when someone careens into the top floor of an office building and explodes into a fireball? Thankfully flying tech has not progressed to reality.
Obviously manual controls would only work outside of restricted airspace; within restricted airspace, you'd be under the guidance of the airspace control computer.
I've always wandered if and how Google would enforce that rule. Now we'll find out..
Given that the policy applies to "Glassware", which is on-board software, and the facial recognition is on a back end server ("not Glassware"), they probably are not going to do dick about it.
If they *were* going to do something about it, it would be to not allow the Dubai police to distribute their Glassware in the Google store. I'm pretty sure the Dubai police will be side-loading the client app anyway, and would be just as happy that *NOTHING* from the Google store got onto their officers Glass devices anyway.
Slashdot Mirror
If my kid shatters my neighbors window with a bad swing I'm liable, why shouldn't I be liable for wrongdoing of my kid in cyberspace?
What's a baseball? What's a bat? OK, smartass, what's a window?
Or are you going to hold the parents responsible for not being Vint Cerf?
If your kids happen to make money, parents control that money until they are 18. They should also suffer the liability as well.
You can't have one without the other. Either children are responsible or they are not.
You have it wrong.
The page was created on a school computer while the school was acting in loco parentis for the child. If anyone should be held responsible *instead of the child, whose fault it is*, it would be the school, with "contribution to the delinquency of a minor" by the "friend" who helped them create the page.
At worst, the parents are guilty of "contributory negligence" for not being software engineers.
Except 640 frozen eggs should be enough for anyone...
And a prototype by 2017!
This gives me a really good feeling. :)
Don't you actually mean "a nice warm feeling"?
10.5 ran on Intel. Making Classic run, but only if you were using PPC hardware, was not an option, due to the large amount of kernel and interface changes necessary to support Intel.
Back up for a moment though, and you're recall that 10.4 supported Intel, which I believe would mean that those changes had already been made, wouldn't it? The way you guys avoided having to do a rewrite of Classic was by maintaining separate builds for PPC and Intel Macs during Tiger's run, with the PPC builds featuring Classic support and the Intel builds lacking it. Couldn't that pattern have been carried forward into 10.5, given that PPC hardware was not long for the world anyway? Instead, Apple merged the builds in 10.5 (which only lasted for that one version), which necessitated dropping Classic for the reasons you said.
The 10.4 Intel builds were "a" versions. The intent was always to integrate them, but they were run as a separate "build train". This is the same way that development versions are handled, and it was the same way that Mac OS X Server versions used to be handled.
To carry it along, it was necessary to build and designate an entire "build fleet" - systems in a server room used to do the builds - and to staff build engineers, and integration engineers, and duplicate roles between Intel and PPC development, etc.. So there was a significant cost associated with it, including that things were not being "built fat". This meant that if you made a change in the PPC code that happened to break the Intel build, since you personally didn't have an Intel system, to do the test builds on, let alone try to run the code to make sure it still worked, someone had to clean it up for you so that it worked on both Intel and PPC. It was incredibly burdensome, and it meant that those people, who were bright people, were stuck working on that, rather than the next great thing.
Technically, it could have been done, but it didn't make economic sense, and it didn't make resource sense (at the time, in Silicon Valley, the feeling was that Google was hiring all available talent so nobody else could hire them, regardless of whether or not Google actually had anything useful for them to do with their time or not).
I'd agree that it was an economic decision, as part of getting people to stop buying PPCs, and to stop waiting on buying Intel, when a purchase was going to happen, but there was still a choice of one or the other. But it was also a resource and process overhead problem.
THIS. Mod Parent Up.
So Oracle certifications just lost the 'D' in ACID ... that's just LOL!
If Intel support for Classic was the issue, then why not ditch Classic after 10.5, instead of 10.4? After all, PowerPCs were still supported for 10.5, so Classic could have been kept around without needing to port it to Intel.
10.5 ran on Intel. Making Classic run, but only if you were using PPC hardware, was not an option, due to the large amount of kernel and interface changes necessary to support Intel. It would have basically required a complete rewrite of Classic. At the time there were just two people supporting Class vs. changes to the main OS (Alex Rosenberg and one other person), it would have require dedicating a team of people to work under them in a non-protected mode environment in order to do the work.
Most of the original Classic team had either already escaped to the iPod division, to avoid having to learn how to deal with the "inconvenience" of memory protection (think "thePort"), or they'd buckled down, and learned to live with protected mode restrictions, or they had left Apple for other companies (Adobe, etc.).
It would have required a lot of hiring to deal with the amount of change that Intel brought to all of the Mach interfaces and other parts of Mac OS X, and frankly, it would have taught them bad/obsolete programming habits, and provided little value to the company, while at the same time making the trade-off between the Intel and PPC value propositions in the wrong direction, when both types of systems were still for sale. This would have not only caused new PPC sales to cannibalize Intel sales, it would have also stretched out the support timeline for the PPC another 2 years.
All in all it would have sucked, a lot, from many perspectives.
Not trolling, just a serious question: why can I compile any software from early 90's to today on any Linux distro I've attempted without issue? It sounds like I shouldn't be able to, but it takes less than 20 minutes of finagling to compile ancient POVray software from the 90's on literally any current Linux distro.
Technically, you can't. A lot of people were still using pre-ANSI C compilers in the early 1990's, so the code will be K&R C rather than ANSI C.
Any software that uses a function name or variable that uses what's now a keyword in C89 or later won't compile correctly, it'll barf. Try naming a function "void" or "restrict" or "const" or "volatile" or typdef'ing something named "_bool". Likewise, you should try compiling most of the contents of the comp.unix.sources archive, and noting the fact that -std=c89 requires ANSI C constructs, rather than K&R C constructs.
Global variables may be caches in registers in later compilers, while depending on changing a value from another thread of control (either a thread, or from a signal handler, etc.), where changing the backing value won't modify the register contents because the contents are not re-fetched on reference... i.e. compiling with a compiler that depends on the "volatile" keyword for the validity of its optimization assumptions (technically compiler writers could have introduced a "nonvolatile" keyword instead, but didn't because they wanted to lazily make the assumption and have the programmer correct it, rather than being conservative about their assumptions).
I expect that you will also see a lot of "cast discards qualifier", "comparison si always true" and similar warnings that would be errors, should you enable -Werror.
Additionally, you're going to find incompatibilities in the use of pty's, and in the use of trmio vs. termios, and other SVR4-ism's vs. BSD-isms (example: do system calls automatically restart after a signal handler fires, or do they terminate the function call with EINTR?). You will also find threads differences (such as PTHREADS_MUTEX_INITIALIZER) which will bear on your ability or inability to declare an initialized pthread_mutex_t, or need to call pthread_mutex_init(). You'll also find that OOB signalling on TCP/IP sockets behaves differently on BSD 4.2g based TCP implementation - and the code that expect a 4.2g sockets implementation - vs. later 4.3 sockets interfaces. For SVR3 and SVR4.0.2 code through 1994, you'll also see portability problems with ntoa vs. the libTLI interfaces, which lost out to the BSD interfaces for socket and host name lookup.
If you are using setuid/seteuid/etc., you will also find that older code assumes the non-existance of POSIX saved IDs - in other words, it believe that you can flip back and forth easily. Not only will this not work without jumping through an additional hoop, you're going to have security holes if you were to "fix" the system call interfaces to behave in the old way.
What you actually mean is that you haven't *noticed* any problems, in doing a not very exhaustive survey of older software. If you tried to use an older gcc that supported the K&R C dialect as a -std= argument, you'd find that the system header files with ANSI C prototypes wouldn't compile correctly.
That is not possible on Mac OSX (I've tried repeatedly, even with homebrew).
I would like to agree with you, maybe I don't understand what the problem truly is, but there is definitely a difference between compiling software for Linux vs Mac OSX. As in, one is so easy a talented kindergartener can do it, while the other is literally impossible without rewriting Mac OSX. Why is that?
Are you only trying to use POSIX interfaces on Mac OS X, or are you trying to use additional libraries supplied by the OS historically, but not supplied by the current OS version? If the answer is the latter, then the problem is that your software isn't portable, because it doesn't engage in minimal use of
I can answer these, as I was there.
"Hey, how come this new version of Mac OS doesn't work with any of my old Mac OS 9 software?", said Mac users in response to Classic support being dropped with the release of Mac OS X 10.5.
Because Apple was unwilling to port the Classic 68K emulator to Intel because of the difference in processor byte order, among other things, making such a port not worthwhile in terms of performance of the Classic software. The user experience would have been crap, and so the decision was made by upper management to not support Classic going forward on Intel.
For the PPC versions of Classic, they could have been supported under Rosetta, but it would have meant an approximate doubling of the number of APIs that were dragged forward onto Intel, for the dubious benefit of "Some Classic software will run, and some won't; sorry the stuff you personally care about doesn't".
"Hey, how come this new version of OS X doesn't work with any of my old PowerPC software?", said Mac users in response to Rosetta being dropped with the release of OS X 10.7.
This one was more related to the lack of a willingness to "freeze-dry" old versions of the libraries. The Mac OS X B&I ("Build and Integration") process required building from scratch the libraries, when building them fat, even though this was a process decision, rather than a technical one.
Effectively, it's not practically possible within the Apple process to reproduce a binary build that's identical to a previous binary build. This is because Mac OS X builds are hosted on a system where the builds depend on being incrementally built into the host environment, rather than actually cross-built to the target. What this means is that the "build from scratch" process to produce the PPC portion of the fat binaries for all the system libraries couldn't be pegged at a particular Mac OS X version, while moving forward with the Intel portion of the binaries, and therefore it was not possible to maintain binary backward compatibility - which was what both Rosetta, and before it, Classic, existed to do.
Debian Linux has this same problem when you build in a chroot to avoid "polluting" the host build environment. It's one of the reasons a build chroot is used by Linaro to support ARM architecture builds on Intel, and that's the same reason that ChromeOS for x86 is built in a chroot environment on a debian variant maintained internally for desktops at Google, rather than being simply directly cross-built into a directory tree hierarchy.
Unlike FreeBSD, neither Linux nor Mac OS X is capable of targeted cross-builds, without pollution of the build/host environment, and without using build products as part of the build.
So technically, the answer for both Linux and Mac OS X is the same: poor build environment engineering - "Worse is Better", exactly what the original article talks about - infects both operating systems.
Germany had the last laugh... German has always been "one space after terminal punctuation in sentences", and since 2009 or so, that's been retcon'ed into English as well: "Ha! Take that English speakers! You may have won the world wars, but *WE* took the second space after your periods!".
It's true that they kill birds. But so do cars and skyscrapers. And I'd wager that coal - between the waste disposal, emitted mercury, and mining - kills birds, too.
OK, as long as they *selectively* kill birds.
I mean, if all they killed were pigeons, that'd be fine, right? We might even build more of them, even without the subsidies...
given the difficulty of carrier certification
What is this difficulty? When a new iOS version is released the ability to get it isn't dependent on carrier certification.
Yes, it's dependent on carrier certification if there is a new version of the baseband software that runs the Software Defined Radio. A lot of Android phones run the baseband on the same CPU as the rest of the smart Phone; Apple phones have a separate processor for the baseband, so it's not an issue for Apple, but if, for example, you are running a Qualcomm Snapdragon processor, the baseband typically runs in a separate hypervisor.
As of the Qualcomm Snapdragon S4, the architecture has changes to run as aSMP, so this is less of a problem, but it still requires certification of the baseband, if there's a baseband update as part of the BOM update. Many so-called smart phones, however, are still running the baseband on a partition of the application processor - meaning you certify with the carriers.
Carrier certification in general is a PITA, because you have to do it separately with each carrier that maintains its own communications infrastructure (meaning that as long as you certify on all the carriers which are selling services to a given VNO, you can get the VNO certification for free, but you have to do it on *ALL* the carriers they use. So it's also a separate step for each country, as well.
Also, you should be aware from the rest of my posting that carriers have absolutely zero interest in you obtaining the most recent version of Android so that you can run out your contract with the most recent version, instead of having to re-up your contract, and get a new phone to get a more recent version of Android. In addition, a lot of the productization changes, including any last minute device support improvements, and so on, are not given back to Google for future use - meaning that it's effectively a new port of Android to the platform, to get an updated version.
I just can't see what the point of ChromeOS is.
[...]
But there's no such excuse for Google. They've got lots of money, lots of talent, and they even have a much better ChromeOS alternative: Android.
ChromeOS: A better Android.
Android has never really been productized by Google. ChromeOS has been; it's a finished product, unlike Android.
One of the major problems with Android is that companies shipping products based on it do not pre-announce. The upshot of that fact is that you end up with every Android version being a snapshot of the Android development tree, which carries the same version numbers/names as other Android products from other vendors, but which have incompatibilities. The one saving grace is that the devices are *mostly* running Dalvik, which is *mostly* binary compatible between the same major version of Android, when *mostly* the vendor partner didn't happen to stub its toes on a major library change for an important and commonly used library.
What drives this incompatibility is not only that the Android running hardware is not specified uniformly in terms of capability, screen resolution, input methods, and so on - ChromeBooks *are*, BTW, and so are Apple devices, for the most part - but the business model for the cell phone industry actively discourages manufacturers from pursuing upgraded versions of the OS on existing cell phone hardware. Because it doesn't sell more cell phone hardware, and it doesn't sell more cell phone contracts, and there's no real App ecosystem like there is in the Apple world.
So upgrades are a net negative to the manufacturers, like Samsung, who wants to sell widgets, and they're a net negative to AT&T and Verizon, etc., who want you to have a reason to want new hardware in order to get the new version of Android so that can catch you up in a new contract for the next 18 months until the next widget comes out. And while Google would like everyone to update the OS whenever Google releases a new version, the company rivalry between the licensees will keep their development from ever being open enough that Google will be able to control the productization to the point of being able to drive an App marketplace on the order of the iTunes App store, because they aren't building it themselves. So there's no money in it to drive Google's desires to reality.
So what's point of ChromeOS? It gives Google Apple-like control over the user experience on a platform where they control the update interval and frequency, and specify the hardware closely enough that, while it's not an iPad or an iPhone, it's a close enough analog.
And that's IMO why Android was moved under the same people who ran ChromeOS, rather than the other way around, and why the Android folks are reporting to Sundar Pichai, rather than his organization reporting to Andy Rubin.
I think the hope was that Android would be able to be productized by the only other organization within Google that's been able to successfully productize a hardware product (well, I guess now there's ChromeCast, but Rishi Chandra reports into Sundar's organization, too).
Personally, I don't think this is going to work out for Android, unless there's a delay built into the version releases for supported hardware, and then given the difficulty of carrier certification and getting the specific version on, and the carriers and the widget makers get on board with the idea, which is a lot of ducks to line up in a row. Plus the carrier and manufacturer buy-in would likely come at the cost of any potential profit off an App marketplace for the first few years, unless the plan was to allow third party marketplaces (which I think would be a mistake).
So ChromeOS is a model for what Google would have liked Android to be, but failed to achieve with it.
...if you're going into a CS program. This holds in general with AP tests, don't take the ones in your intended major, because you're unlikely to get useful credit for them. This varies from school to school of course, but it's generally true.
Totally disagree. I took 5 AP classes in High School in ~1980. I was the first person in my High School to achieve this number of AP classes, and I was able to skip my freshman year of college and immediately begin taking more advanced math, physics, chemistry, honors English, and when I discovered them, CS courses. I was well on my way to multiple degrees, while most of the people I went to High School with were still deciding what to major in.
Testing out of a class is a more iffy proposition. I found that CLEP testing, at least for information learned as an autodidact, rather than in a classroom and labs, as the AP credit was, tends to give you spotty coverage of a subject, unless you are going to read the textbook for the course you intend to CLEP out of from cover to cover, and do the exercises. It also can somewhat rob you of a year in college; it's actually quite easy, by combining CLEP and AP testing, to drop your distance to a Bachelor's degree to two years. Less, if your college/university administration allows you to carry ~20 credit hours, rather than the "normal" 12-14 (admittedly, this can still be a deal, if you are there on academic scholarship, and your parents wouldn't be able to pay your tuition for you otherwise). This will generally translate to one fewer internship, and one fewer year of college social life, such as it is.
Practically speaking, I'd say that piling on the AP classes is a great way of saving money in the long term by front-loading the costs of college credit onto the state, rather than having it come out of your, or your parents, pockets, especially if you can't afford it. Assuming you apply yourself and do well on the tests, it's also exactly the thing that a college or university is going to want to see, should you apply for an academic scholarship, and between that, and a Pell Grant (now called BEOGs), it can cover your tuition, books, and living in the dorms, which is, for a poor person from a poor family, your entire opportunity for a higher education.
Why was he so inept at business - how the hell did Westinghouse screw him over?! Tesla was a genius but got screwed over by a business guy? Really? Was he THAT gullible?!
Typically, you trust the people you are working with the first one or two times, with the expectation that they will also trust you. Then your trust gets violated, and you either learn caution (e.g. "Get everything in writing"), or you continue to get screwed. If you've ever read the book "The Evolution of Cooperation" by Robert Axelrod, a perfectly logical player in the mutual security game will operate for mutual long term overall benefit, rather than short term benefit for themselves. Sadly, not everyone is entirely logical, and for many of those persons, it's not enough that they have more as a result of your mutual efforts, for them to feel good about it, *you* must have less.
No, not free. This is a scale proof of concept.
Grown ups in grown up fields discuss concept,they are talking about actual design concept. Completely different then the 'concept' that you and your buddies come up with while drinking cheap beers in you pickup.
The problem was (and remains, despite vortex-based and similar proposals), "ash removal", which is to say, getting rid of the He generated as a fusion by-product to keep it from damping the fusion reaction. It was a problem with the TFTR Ttkamak in 1982, and was a problem with the NSTX, and it's a problem with this follow-on device, the spheromak (of which this article is reporting an example, dynomak).
The problem was never containment (and this dynomak, as all spheromak's, has some really clever mechanisms for containment), the problem is *still* He ash removal from the reaction plasma mixture.
So when you are ready to talk to "grown ups", leave your graduate student class projects, and address the ash removal problem, please.
Because he might want to have a decent relationship with them? Other then this issue, it might be a great product, might be getting a discount and so on.
Future relationship?!?
So they can buy *more* products with bugs an unresponsive support in the future? I can see why you'd want to protect *that* relationship...
Concepts are practically free.
As long as you never build anything, free is always "cheaper than coal"...
Ironically...
Crime Agency Boss Must Trade Job For Dole, Says Brits
Obviously manual controls would only work outside of restricted airspace; within restricted airspace, you'd be under the guidance of the airspace control computer.
I love the aviation consultants on this forum...
You do realize that we are no longer talking about Cessna's with Hemi's and whitewalls, we are talking about VTOL craft at this point, right? And some of us do have pilot's licenses, so we realize how ridiculous this particular vehicle is, right?
Funnily enough I think flying cars could be a better target for automation than those disastrous ground-based driverless cars.
The problem space is much more defined in the air than on the ground and, given that it's difficult for a human to look in all directions at once or judge distances of rapidly approaching objects, should probably be mandatory.
With a reserved airspace that has no manually controlled vehicles whatsoever, it's definitely a better target for automation (assuming quadrotor style manueverability). The thing that makes the ground hard is the manually controlled vehicles, the people, trash cans, road surface damage, and other mobile obstacles. Take that away, and you no longer need vision systems or any of it.
In case you don't drive much, its already too scary with cars on the ground. Can you imagine some of these idiots flying around? The horrendous crashes? Care to think about what it would be like when someone careens into the top floor of an office building and explodes into a fireball? Thankfully flying tech has not progressed to reality.
Obviously manual controls would only work outside of restricted airspace; within restricted airspace, you'd be under the guidance of the airspace control computer.
I've always wandered if and how Google would enforce that rule.
Now we'll find out..
Given that the policy applies to "Glassware", which is on-board software, and the facial recognition is on a back end server ("not Glassware"), they probably are not going to do dick about it.
If they *were* going to do something about it, it would be to not allow the Dubai police to distribute their Glassware in the Google store. I'm pretty sure the Dubai police will be side-loading the client app anyway, and would be just as happy that *NOTHING* from the Google store got onto their officers Glass devices anyway.
So it's a non-issue.
Seems to me that would only make things worse when your libraries have bugs: Why rings 1 and 2 aren't used?
That reference does not seem to indicate it would be a bad idea, only that "the benefits are reduced".
Ring 2 on VAX hardware is where installed system images (read: like libraries) ran. Same place they run on OpenVMS on Itanium.
People who do not know history are doomed to keep pounding their heads against a brick wall until they repeat it correctly.