Follow Slashdot stories on Twitter


Forgot your password?
Last Chance - Get 15% off sitewide on Slashdot Deals with coupon code "BLACKFRIDAY" (some exclusions apply)". ×

Comment Re:Confusion ensues... (Score 1) 61

I should have clarified that to be ARM chips. By the time Jobs came back, Apple had long moved out of making chips.

Still not really right, except for the narrow issue of Apple not visibly doing any custom ARM CPU work between the ARM610 and buying PA Semi. A lot depends on what you mean by "making chips" because they have never owned their own fabrication plants, but there has always been some Apple-labeled, Apple-only, and at least partially Apple-designed silicon shipping in Apple devices since 1983. In the sense of running a fab, PA Semi also never "made chips." However:

Every Mac (even every one of the 90's PPC Mac clones) has included one or more custom Apple logic chips. Apple also used some PPC CPUs that were not available to anyone else, although their input into the "AIM" consortium that did PPC design was never entirely clear.

Every iPhone and iPad and most (maybe all, I'm not sure of some Shuffle and Nano models) iPods have included one or more custom Apple logic chips.

Most of the computer manufacturers had started to use more and more commodity parts. By the time IBM sold off their PC business, an IBM motherboard might be custom made for IBM but most if not all components could be bought separately. In the early 90s that motherboard might have had some IBM custom chips (ie, micro channel).

Sure, but not relevant to Apple. IBM's choice from the start with the PC design avoided custom logic to hold down development cost (and initially to avoid internal roadblocks to getting the PC made at all.) Once the BIOS was cloned, anyone could build a PC. In a sense, Apple went the other way: integrating functions performed by multiple commodity chips and their own code in early machines into custom ASICs in later machines and model iterations, trading development costs for production costs and thwarting cloners in the process. In the 90's they never fully enabled the Mac clone market (a dubious endeavor that Jobs killed) because they never weaned MacOS from their custom logic. It wasn't until the switch to Intel CPUs (2006) that the Apple custom logic was reduced to a small enough and deep enough set of roles (e.g. SMC/PM) that it was feasible to run MacOS on machines lacking Apple's custom chips. It's true that for a year or two before the PA Semi acquisition they had effectively outsourced all of their chip design to fab partners, but that was a short-term anomaly in a long history.

Comment Re:Confusion ensues... (Score 2) 61

Apple didn't make chips before PA Semi;

Except for chips like this: Late Apple ][ models, Lisa, Newton, every Apple printer since the Imagewriter,, every Mac, every iPhone, and most if not all iPods have included one or more chips designed by Apple, carrying the Apple logo, unavailable to anyone else, and usually very poorly documented (if at all.) One could also argue that the 680x0 and PPC versions that Apple commissioned for exclusive use in Macs amounted to them acting like a fabless CPU maker (e.g. like PA Semi) so if you meant "CPU" instead of "chip"

Comment Re:Hmm... (Score 5, Informative) 165

Ohhhh so its going to be systemd for BSD?

Yes and no.

Some of the legacy Unix issues that systemd is supposedly intended to address have been attacked by Apple in the tools NeXTBSD is adopting: ASL, LaunchD, GCD/LibDispatch, NotifyD, etc. Note that unlike systemd, the Darwin replacements for traditional init, cron, & syslog aren't monolithic and are relatively mature. LaunchD & ASL have been evolving for over a decade in mass-market OS releases and it is apparent to anyone using them attentively in MacOS over that time that Apple has been working to make them actual improvements for admins and developers interacting with them over the legacy tools, rather than merely replacements. They were both problematic in their earliest releases, but they both have been developed over time to the point where they no longer seem like the products of CS theoreticians who've never managed real systems.

Beyond that, I think it is safe to assert that there is MUCH more well-earned community goodwill towards Hubbard & Macy than there ever has been or ever could be for Poettering, so the social drama isn't preset for tragedy in the event that the project is unremarkable for a while.

Comment Re:Uptime fetish (Score 1) 409

Theoretically "most" but far from "all" for Solaris 9, and no one with production Solaris 9 boxes works that way. The patchadd of Solaris 9 vintage, its dominatrix install_cluster, and the normal pre/post scripts in Sun's patches assume that you are patching in singleuser and don't need such arcana as modunload/modload and rem_drv/add_drv. It might have been possible in principle to pick apart most of the patches from Sun's "Security & Recommended" cluster marked "REBOOT AFTER" or "REBOOT IMMEDIATELY" and devise a method to apply each one without a reboot, but since I'm certain that the core kernel images (for the 280R: /kernel/genunix and /platform/sun4u/kernel/sparcv9/unix) were changed multiple times for Solaris 9 2003-2008 (when last I worked with a few score such machines), it is not possible for any amount of artisanal recrafting of patches and their mechanism of application to have kept this machine or any similar machine both patched and running for a decade.

Comment Re:What is Perl? (Score 1) 379

Perl is a historically a combination of bash, awk and sed.

There's the first clue that this is a troll. Perl was devised to replace the model of using a Unix shell to wire together bits of sed and awk, but the shells that informed the creation of Perl through v4 cannot have included bash unless Larry Wall has a time machine. There's certainly some sh influence in Perl and maybe csh as well, although one could believe that the influence was a desire to redeem the idea of a C/sh hybrid from the mutant horror of csh.

And for purposes well suited where people would use the former three tools to implement shell scripts to help administration tasks on a daily basis. However, Perl is not so well suited for other purposes, like small and medium sized web applications.

Um, yeah... because apps like Slash, RT, and Movable Type are really large and frameworks like Mason and Catalyst are overkill for anything modest. Or maybe I am reading you wrong?

More directly: It is absolutely true that a lot of sysadmins use Perl as a shell alternative for text processing and that it has its roots in that problem space. However, it also was the overwhelmingly dominant language for web application development for many years and its extension to that job largely defined the functional space for what a web application language has to do. Perl is a procedural language from its roots, but it also has a mature object implementation and a rich universe of modules using it that include multiple frameworks for web applications. IMHO most of the perception of Perl as less "suited" for web development is a result of the diversity of Perl code aimed at the web. There isn't an obvious single stack of Perl modules to use as a basis for all web apps (i.e. an analog to Rails) but rather a bazaar of options that make sense for different sorts of app. It is certainly NOT suited to casual amateur web development.

Therefore, it will not gain any more ground in that area, as better tools are available. The first Perl enemy was PHP. While PHP sucks in many ways, it was better designed to write simple dynamic web pages.

Not really "better" but rather "only," at least in its origins. It is inevitable that a language created to be web-specific at a time when most web development was done in languages designed for more generalized use (e.g. Perl) would be better fit to that specific purpose, at least in the most trivial ways. It certainly makes PHP more accessible for low-skill coders, a fact demonstrated by the unending stream of fundamentally simple security problems in widely-deployed PHP code.

Today it is used for medium sized web applications, which is clearly a dangerous thing, but still it restricts the growth of Perl in that direction, as younger coders came first in contact with PHP and all the hosters support PHP, but not everyone is supporting Perl. Also things like Joomla or Typo3 are PHP based and many people start coding by extending them.

Yes, PHP has largely soaked up the pool of interest of casual code tweakers and it is much easier to offer commodity-grade hosting with credible PHP functionality than it is to do the same for any other language/platform. That was arguably true for FrontPage some years back and we all know how it managed to take over the world.

For custom application or other mostly larger system Java-based or .NET-based technologies are used. Perl has nothing to do in that area. It lost its job there many years ago. InterShop was once coded in Perl, but - well - who cares?

There is more diversity in large-scale and custom enterprise web applications than you admit. In many cases big Perl systems have not lost their jobs, they've just matured and stabilized. Movable Type is a great example: it is still the engine behind a lot of very large websites but it has lost buzz to weaker platforms over the years because it isn't constantly being updated for idiotic security flaws and has never been suitable for commoditized deployment by low-clue hosters. It isn't being displaced by anything else, rather it has become part of the mostly stable infrastructure of those who use it rather than something that demands constant attention.

As the Unix command shell is only a limited realm (in number of installations), Perl will never become that widespread again. At least that is my assumption considering today software base and structure, as well as the education in programming languages.

A non sequitur based on a ridiculous assertion. The idea that Perl is somehow dependent on the "Unix command shell" (by which I assume you mean a shell similar in function to the classical "/bin/sh" on an OS that is significantly Unix-like) is delusional. Referring to the number of installations of such shells as a "limited realm" is a formal truism in a finite world and the limitation is further constricted by the existence of Windows servers, but it is a bit misleading. The fact that a web developer or website content owner can't run an interactive shell session on a server is no indication of the existence or other use of a shell on that server. It is also not inherently an impediment to the use of Perl for web development on a server. The most significant commonality between Perl and shell is that they are almost universally installed as core tools on non-Windows/non-mainframe platforms.

Comment Re:Imagine that.... (Score 3, Insightful) 477

Where does it say he was incompetent? It says he was fired because he kept bothering other employees with his ideas.

I know it violates /. tradition and may even be deemed "cheating," but there's at least one link in every /. post leading to a direct source article, which YOU CAN ACTUALLY READ ALL BY YOURSELF! In this case the referenced article links to another more detailed and specific AP article that details the bozo's workplace failure.

It is worth noting that for support staff (in this case a "computer specialist" on the Cassini project) not being a nuisance to co-workers is a critical and fundamental job skill. So is maintaining the respect & trust of the people doing the core work of the organization. JPL was correct in providing evidence of Coppedge's bad attitude and workplace evangelism as part of the argument that he was cut for perfectly sound reasons. Working well with others is a perfectly legitimate job requirement and failing to do so is a competence issue in many jobs.

Comment Re:And they'll still buy the next iPhone (Score 1) 466

Most of their customers will grumble about it, and guess what? They'll still buy the next iPhone. Apple's marketing really helps them here.

Most??? You use that word, but I don't think it means what you think it means...

The key aid here from Apple's marketing is that Apple knows who their customers are. The "loss" of the Transit info isn't very meaningful for Apple's customers and frankly it is worse than useless in Google Maps for many people now. For example, Google has incomplete and inaccurate info for the SMART bus system that serves (for a loose definition of "serve") the Detroit suburbs. Are they better in other places? I can't possibly know but I wouldn't ever trust that feature given that I know it to be routinely wrong. Do iOS users actually get anything useful from Google's Transit misfeature? I can't know the answer to that but you can be sure Apple has at least a partial answer and has some grasp on how well such a feature can actually be implemented. My guess is that Transit is a feature that would not be capable enough for enough iOS users to be worth doing. If most iOS users even notice losing transit info as a Maps feature I'd be surprised.

As TFA notes, it is very likely if not certain that Google will be offering their Maps app for iOS 6 independently, or maybe rolling the functions into their existing Earth app. How many people will grumble and for how long? I don't know with any certainty, but I'd be surprised if it is "most" by the standard definition.

Comment Re:Prior Art? (Score 1) 98

If the Twin Peaks patent is on GPL-violating code,

Thank you for playing, we have some nice parting gifts for you...

A patent is not "on" a specific piece of code, but rather on a method of doing something useful. Specific code is covered by copyright. GPL is a copyright license, not a patent license.

Comment Re:Arrrrrg (Score 1) 87

I may have this wrong, but isn't this exploit only possible if you have Java enabled in your browser, which you only need to run Java applets?

Or Java Web Start, which is basically downloaded (rather than embedded) applets

When was the last time you saw a Java applet?

The last time I needed to work in a single-user interactive shell on the console on one of our servers. It's been a few weeks, but when I need it, I NEED IT. The access mechanism that actually works is a dynamically generated JWS applet with embedded temporary auth tokens. A rather slick way to do safe working console access compared to some of the broadly dysfunctional and/or unsafe approaches I've seen.

Disable it. I'm surprised it's still enabled by default (I think it's actually disabled in Chrome).

I don't believe that any current browser+OS combination has Java installed and enabled by default. Chrome is slightly special, apparently because it is a 32-bit app and it takes some manual effort on a 64-bit OS to get a 32-bit plugin. For modern MacOS, there simply is no 32-bit plugin and so no Java for Chrome no matter what.

Comment Security questions are designed to weaken security (Score 2) 408

They are de facto alternative shared secrets used for authentication, so that instead of there being just one password that will open an account there are more. Because the answers are mostly things we don't think of as particularly secret and many systems use the same sets of questions, the result is what everyone knows is bad practice: a weak password used in many places.

The right fix for the "security question" mess is not better questions or trick answers, it is to eliminate the process that demands them. A human-mediated password reset process is always going to be subject to social engineering and if the humans mediating that process are low-skill CS reps whose work is only deemed to be worth the prevailing call center wages in Chennai or Manila, the social engineering is likely to be unchallenging. If you must offer a way for a user to recover an account for which they've forgotten the password, it should not be vulnerable to attack via research or pleading.

Comment Correct link to cited Vixie post (Score 5, Informative) 163

As has become all too common the /. summary is linked to a negative-added-value article at the totally worthless IBT.

Paul's actual post is at CircleID: and is over 3 months old. Not news. As is normal for Paul it is well written and smart but if you've been following DNSChanger, you've read this already.


Submission + - Google's Artificial Brain is learning about cats ... from YouTube (

NemesisEnforcer writes: "Google has apparently been working on one of the largest neural networks ever produced in their X Laboratory. The software has been given access to the Internet to freely learn, and it has decided to move in a strange direction. Apparently funny cat videos on YouTube are a great primary source of zoological information.

John Connor, use the kittens!"

Our informal mission is to improve the love life of operators worldwide. -- Peter Behrendt, president of Exabyte