My main machine these days is a dual 2GHz G5 (aka PowerPC 970) - it's physically a regular Apple Mac, although it obviously only runs Linux
Which is a shame, as running both operating systems from time to time can be a useful shift in perspectives, and -- not that this is what Torvalds works on, but regardless -- Linux could do for a vastly improved desktop environment.
Linux creator Linus Torvalds said this afternoon that he's now running an Apple Macintosh as his main desktop
I feel so validated right now.
I've been using Linux for a decade now, but dammit there's only so much pain I'm willing to endure from my desktop computer. X11 sucks, and it's holding Linux back. I've given too many hours of my life fighting against arcane config files just so I could get a mouse to work or a display resolution that didn't make my eyes bleed. Never again. I've got more much better things to do than that.
It's nice to see that the leader of the Free world appears to agree:-)
I'm curious to see if this will be a motivator among the groups that have been messing around with a "usable" desktop Linux for years now without actually getting anywhere...
How does defeating a measure designed to block your ads make good business sense? Does forcing your ads upon someone known to hate your approach produce good results? Does irritation equal a higher rate of return because people who hate your ads see them and have a change of heart? Do they say, "Hey, I had no idea those hateful ads were so interesting and useful to me. I think I'll buy their product."
As with anything else, the answers to such questions would depend on who you're asking and what their motivations are, but to hazard some guesses...
To the ad executive that has his or her staff work on implementing their popup / popunder ads, they're defending their business model. Popup blockers were possible for them to ignore when they were limted to fringe browsers like Mozilla, but now the fringe browsers like Firefox & Safari are getting more popular, and even IE has implemented a popup blocker. If left unchecked, this would put these executives out of work within a year, so developing countermeasures now is a career preservation tactic.
Moreover, some ad execs may really believe that users want to see well executed "interference" ads (popups, full screen delays ads, etc_), even if all available evidence suggests otherwise. In the end though, these people need to be able to convince their web publishing partners that popup ads are effective & profitable; this has been true to date, but to keep that claim credible, they can't ignore blockers.
To the web publisher, popup ad placements can be sold for a premium over other ad types, so preserving a market for them seems to be in their best short term interest, even if audience irritation will force them to abandon the format in the long run. But for these people, the real customer is advertisers, not audiences -- audiences are the product that gets sold to the advertiser, not the other way around -- and if the advertisers are only willing to pay for these new "blocker busting" popups/popunders, then they have no choice but to run the ads that way. They don't necessarily like being in this position -- they have to be aware of how annoying this is to their audience -- but they can only switch to something else once another source of replacement revenue is found. So far, aside from some experiments with registration &/or subscription models, most sites haven't found an alternative revenue stream yet.
To the front line programmers & admins implementing these counter-blocker techniques, a lot of them are probably just focusing on whatever pays the mortgage, whether or not they are concerned about annoying millions of web users. Maybe they complain, but don't have the weight to get their employer to reconsider. In the crappy economy we're stuck in, jumping ship might be seen as too risky; maybe they like their jobs otherwise; maybe they see things eye-to-eye with their managers and want to preserve the current business model.
Etc. Different people will have different motivations, but within broad classes like the ones above -- advertising executive, web publisher, technical staff -- I think the motivations above along the right track...
The UI is definitely slick, but it definitely has some quirks, some annoying. Some random observations:
The maps seem to be three dimensional. Look at the map of a complicated highway interchange and you'll see that it seems to get the over / under ramps correct. (For example, look at this map & zoom all the way in -- it pretty accurately reflects a complicated, braided set of onramps & offramps).
On the other hand, it's not completely three dimensional: while the map has surprisingly current data for Boston's Big Dig, for example, it doesn't actually illustrate the points at which the roadway goes underground. Considering that some of these tunnels have surface roads over them, or will in the future if they don't already, finding a way to denote a tunnel seems important.
It doesn't show one way streets! This is absolutely essential, especially in urban areas where a lattice of one-way streets can force you to take convoluted routes to follow the seemingly simple paths you could have taken if all the streets were bidirectional. A map service that can't show this data is much less useful than one that does. (That said, the trip planner does seem to show routes with an awareness of one-way streets, and will plot different to & from directions accordingly. So they do have the data, and they do use it where it matters, but they aren't making it visible in the interface. This may have been a deliberate attempt to constrain against information overload, but in this case I think the user really does need that data visible, at least optionally.)
While the UI is nice and responsive in a way few other web sites are, it has some idiosynchroncies. For example, if I search to a map, then scroll somewhere else, then go to a different browser tab, it sometimes snaps back to the original search when I come back, rather than whatever I was looking at. If I do a new search, it scrolls to the new location from the old one; while this looks cool and may be the desired result if I'm thinking about directions, other times I may be thinking of a completely new & discrete search, and don't want to treat the two searches as a set -- some kind of "new search" option would be good. (This last one is subtle to describe, but kind of annoying once you pick up on it -- it's definitely useful, but maybe a little too helpful, ya know?)
I like the way it dynamically fills up the current browser window size: note the way the map is always just a bit shorter than the current view is tall. If you resize, the page will start scrolling or have a white margin on the bottom, but will quickly redraw to match the new geometry. Clever.
The overlay of local data seems much more polished than it was with last year's Google Local. Maybe this will mean abandoning Google Local as a separate entity and incorporating its functionality into Google Maps -- they're already most of the way along to doing exactly this.
As widely requested, non-US/Canada data would be nice, but I'm sure such things are on the way. Moreover, Google already pulls interesting geolocation tricks, such that a request for google.com from an internet cafe in, say, Switzerland, will automatically and transparently redirect you to google.ch. Likewise, a search for http://news.google.com will redirect you to http://news.google.com/news?ned=de_ch&hl=de. I'm sure that once this gets going, Google Maps will also automatically send visitors into a mapping application that is relevant to their location.
last year a marketing firm conducted a survey where they asked people whether they thought Xbox 360, PlayStation 3, or Nintendo N5 sounded more 'next-gen'.
Is this Microsoft's version of David Tufnel's classic "Spinal Tap" bit in which he shows off his special guitar amp that was custom-made for him by Marshall and is better than the regular version, because it goes to eleven.
"The 360 is better, innit? Because, you see, it's 355 more than the N5, and 357 more than the PS3."
All they need are exploding drummers and the circle (ahem) will be complete...
It's been said before, but mature industries tend towards three of something
It's been said before, but all generalizations are false.
It's debatable whether GM, Ford, and DaimlerChrysler are the three primary car makers worldwide, and the companies in 4th, 5th, etc place aren't really that far behind the market leaders.
It's highly debatable whether Sun, and so SPARQ, is going to be around in 5 years. They seem to be clinging for life and I'm not sure how they earned a place in your top three list, aside from the fact that you're hell-bent on making a top-3 list out of everything.
The distinction between Linux and UNIX seems academic to me. In practice, I think a better division would be based on the GUI & desktop environment used: you'll have Windows as the primary player, X-Windows based systems running on Linux or Solaris or a BSD as another, and MacOSX as a third. But even that distinction seems fuzzy, as aside from the GUI, MacOSX is a lot like Linux is a lot like POSIX Unix, so in reality we seem to be converging on a dual Windows / POSIX world, not a trio.
{Star,Open}Office is a very distance second to Microsoft Office, on every level: the quality is abysmal compared to MS Office, the functionality is a fraction of what MS Office provides, the userbase is a very very tiny fraction of that of MS Office, and I suspect that the userbase would be even smaller if MS Office ran on *nix so that *nix users could use something that wasn't so godawful broken. As for iWork, it's also not a valid comparison, not least because it doesn't even have the full complement of applications expected in a productivity suite. If a spreadsheet ever gets added to the mix (which seems reasonable, but it hasn't happened so far), that would be different, but lacking that, or a desktop database, it doesn't really compare to MS Office or even {Star,Open}Office. So this, again, seems like a desperate attempt to get a three-player field out of a one-player reality.
For browsers, I agree, though I'd amend that to three families of browsers, rather than specific examples from those families: IE (including niche browsers that use the IE engine to do things like tabs & popup blocking), Gecko (Firefox, Mozilla, Netscape, et al) and KHTML (Safari, Konqueror, OmniWeb).
But aside from most of the facts being against you, it's an interesting point you make:-)
GM does extensive business in Europe (and elsewhere) under the name Opal, and has ownership stakes in companies like Saab (Sweden) and Subaru (Japan).
Ford does business worldwide under the name they use in the US, and owns or partially owns companies like Mazda (Japan), Volvo (Sweden), and Jaguar (UK).
Chrysler is an American division of the German DaimlerBenz. They put Chrysler in the new name DaimlerChrysler, but that was mainly to calm American protectionist fears: for all purposes, Chrysler is a German operated company now.
Of the Japanese companies...
Toyota does extensive operations worldwide, and builds everything they can in local markets. The US Federal Trade Commission considers a car like the Camry to be domestic, because it is mostly built in Tennessee.
Honda also does extensive operations worldwide, and builds everything they can in local markets. The US Federal Trade Commission considers a car like the Accord to be domestic, because it is mostly built in Kentucky.
Nissan is, if memory serves, a partner with the French automotive company Renault. I forget if renault owns Nissan or if it's the other way around, but like Chrysler, it was basically taken over by a "foreign" company.
Of the German companies...
Like the Japanese and American companies, BMW does a lot of manufacturing in local markets. Their SUV and roadster models, for example, are built in South Carolina. Additionally, BMW owns or co-owns companies like Mini, Range Rover, and Rolls Royce (all UK).
As already noted, Mercedes owns companies like Chrysler (US). They also do a lot of work in local markets; their SUV is manufactured in Alabama, and a lot of their cars for the American market are now being built on Chrysler plants.
This is the only example I can think of where the company is mostly what you say it is. Aside from having partnerships with Audi and Porsche (both German), I'm not aware of them owning any manufacturers from outside of Germany. On the other hand, they also build a lot of cars in local markets; the Beetle, for example, is built in Mexico.
So really, all of this is so distributed and interlocked that it doesn't make much sense to divide them they way you have them, or to assert that there are three source countries each with three primary manufacturers. The reality of the situation is much more involved than that...
It's interesting that you say you couldn't enable multiple clients to listen to different audio, as they clearly intend you to be able to do that with the squeezeboxes.
It's been a while since I played with it, but my impression was that it was serving different things based on the client IP address, but if all the clients appeared to have the same IP (e.g. different subnets being bridged by a gateway server, so to the SlimServer the clients all appear to be 192.168.0.1 or something) then they'd all get the same stream.
It probably would have been possible to sort it out, but in the end I just got Apache::MP3 working and used that instead. The interface definitely doesn't look as good as SlimServer does, but for the usage model I wanted to support -- coworkers without iTunes (i.e. Linux users using XMMS or whatever, as the Mac & Windows users have & use iTunes) being able to listen to my shared music library via HTTP -- it works well enough.
But SlimServer is definitely a more flexible design, and I really liked the software. If the opportunity comes up to use it again in the future, I look forward to it.
The most irritating bit of all this is that the guy writes the thing, distributes it, gives it a name (eponymous) and then the stupid virus firms go and butcher it -- e.g. "Lasco.A". What's so wrong with "Velasco" already? The guy clearly wants it to be named after himself."
It's not much of a leap to assert that most malware is, on some level, a form of ego tripping, and most malware authors, much like the authors of any other software, would like to see their work spread far and wide.
Hence, antivirus companies always change the name.
Whether or not a virus had a name to begin with, each vendor will select a name of their own for it to deprive the author of that fame. Why encourage them, you know?
But there's the other bit of ego -- each vendor will select a name of their own. For a prominent attack, one of these names will make it into he wider media, and being the vendor that named it is itself an ego boost for that company.
So, all of this naming nonsense is just a stupid dickwaving ego contest. We'd almost be better off if we did like the National Weather Service and named each year's outbreaks in advance, before any of them are spotted in the wild, just to neutralize the stupid games that go on over what this junk gets called. Not that that'll ever happen, of course...
I was looking at this site the other day. My first impression was that it was a pretty good idea -- you have this cheap little computer that would be more than adequate for running a website &/or mail server, and it's small enough that you could get dozens of them of a single rack.
Then it dawned on me that the Mac Mini doesn't have a fan, and depends entirely on being able to vent heat around the bottom edges and back panel. Apple's site has a document warning users:
Always place your Mac mini on a hard, flat surface to provide maximum airflow to the computer's vents around the rubber base. Don't put anything on top of your Mac mini or stack Mac minis on top of each other either.
Sounds like a dense rack full of the things would be liable to overheat & burn out.
Are these people thinking about cooling issues? Their FAQ page made no mention of it last week, and it looks like it still doesn't now. Would anyone trust a rack full of these things not to cook the circuitry?
Just use SlimServer and be done with it. Read about it here, but to repeat the main features:
It's available under the GPL, so you can do what you want with it.
It's written in Perl, so you can run it on anything (Linux, OSX, Windows, etc)
It provides a configurable web interface to the central music library.
It's intended to be the interface software for the same company's Squeezebox network audio player, which explains why they're willing to give it away under the GPL -- they make their money of the hardware. That also explains some of the unusual design decisions that went into SlimServer, namely, that unlike some other network streaming setups (Apache::MP3, iTunes DAAP streaming, etc) which let each client listen to their own selections, the SlimServer architecture allows multiple clients to have a say over the one stream that's being used centrally. For a management interface to a central home audio system, or for the system described in this article, that design decision is a perfect fit.
Really, give it a try. I tried setting it up on a LAN for coworkers to listen to mp3s on their headphones, and while everyone liked the interface a lot, it was annoying that everyone listened to the same thing. But if you want to provide a way for everyone to set what is being played on a central system, this is exactly the way to do it.
Of course, if we all move to speaking some kind of ubermetalanguage, that implies that the languages spoken today would be lost. That would be a sad thing.
Language is a reflection of culture, and culture, to date, is a deeply regional thing. The standard example is that the Inuit people of Alaska and Canada have dozens of words for snow; while this seems to be not entirely accurate, the general point stands that different groups have richer or poorer ways of expressing concepts based on their collective experiences. This is both a reflection of and an amplification to regional cultural distinctions.
For an example I'm a bit more confident about, Russian has no word for fun. It's a concept that can more or less be expressed with a string of other words, just as "tsunami" can be expressed in English as a string of other words, but the term itself, and so the concept it represents, isn't directly represented by a Russian word. Funny, eh?
Language is full of these little oddities. One of the great things about English is the tendency to gladly pick up terms from other languages when we can't express something already -- cf. "tsunami". If everyone were to speak one doubleplusgooduberlanguage, then this ability to cross-pollinte will presumably go away. That would be doubleplusungood.
But I don't think we're in any danger of that. English may be becoming a "world language", sure, but look at all the regional variations: it can be a real stretch to assume that the Hindi inflected English in India, the Chinese inflected language in Hong Kong & Singapore, the hodgepodge of influences on dialects in the Caribbean, and the diverse variants spoken in the UK, USA, and Australia are really all the "same" language. In a lot of ways, these dialects of English are only growing farther apart, just as the French spoken in places like Haiti and Cote d'Ivorie are much different from the language in France, and the German spoken in Switzerland is much different from the Hochdeutsch in Germany.
You could argue that the Internet may bring all these streams of language closer together, but you could just as credibly argue that it will only serve to churn the already turbulent patterns that are driving languages apart.
Personally, my hunch is that while some kind of pidgin English may come to be widely understood around the world, the predominant trend is going to be increased, not decreased, diversity in global language patterns. And I see that as nothing but a good thing.
Wow that XML is ugly. I'm not a Lisp hacker, but come on, wouldn't that be much simpler & clearer as a Lisp-styled S-expression? Consider (apologies in advance for the faked-out indentation with _underscores_, due to broken comment markup rules, that was as clean as I could get it...):
As I say, I don't know Lisp, I've never coded in it (before 5 minutes ago when I started this post), and I'm not sure how Lisp/Scheme syntax usually captures things like XML attributes, or name/value pairs, etc. But come on, this is on the right track, isn't it? And isn't it waaaay easier to read and understand than the XML version?
If XML is proof of anything, it's that the MIT hackers were right decades ago when they started out trying to win the world over to Lisp. All XML is, is ridiculously verbose Lisp, right?
The French police are planning to switch from Microsoft Office to OpenOffice, the French industry news service Toolinux reports. By the end of January some 35,000 PCs and workstations are to be equipped with the open source office suite; by this summer the number is to reach 80,000. The French police expect to be able to cut costs amounting to more than two million euros by this move. (Robert W. Smith) / (jk/c't)
While it's good to see that le gendarmerie are going to be switching over to everyone's favorite underdog office suite, I don't see where this is the same thing as them all moving to Linux as well. Did a longer version of the article throw in that detail, or was the submitter or the editor getting carried away here?
Yeah, I'm not really sure how this organization scheme could be adapted to Linux.
The $PATH variable works in the usual sense on the command line -- it typically looks for commands in places like/bin,/usr/bin,/usr/local/bin, ~/bin, etc -- but it doesn't appear to be relevant to the GUI, or to the open command which can be used to open files in the GUI (e.g. open -a Safari ~/Sites/index.html).
As near as I can tell,/Applications is the GUI analogue to */bin directories, and the Finder is just transparently aware of everything under there. If you want to launch a graphical application from the command line, you either invoke it with the open command as noted above, or you invoke it directly as, for example, with the Vim GUI:
$/Applications/vim/Vim.app/Contents/MacOS/Vim # a console Vim editor session opens up in the Terminal $/Applications/vim/Vim.app/Contents/MacOS/Vim -g # a graphical Vim editor session opens up in the GUI $
Meanwhile, in the Finder, all you see in this example is a folder vim under the Applications folder, in which (among a couple of other things I have in the same folder with Vim.app) is a single double-clickable application "Vim" with the usual green logo icon. The structure underneath is not at all apparent from this view.
I think the way to get this done on Linux would be to extend one of the graphical frameworks -- GNUStep / WindowMaker would be a good candidate -- to have the same bifurcated view that you get between the Aqua GUI and the command line on OSX. I don't know much about GNUStep, but it's possible that it already provides much of what would be needed to do all this...
So, your solution to "One small directory that's quick and easy to look through" is "a shitload of different directories"?
For values of "shitload" where "shitload" equals "three", yeah.
~/Library/Preferences for user level settings (comparable to ~/.* on other Unix variants
/Library/Preferences for system-wide settings as locally configured (comparable to/etc, and the place where nearly anything you want to grep for will be stored)
/System/Library/Preferences for system-wide settings as installed with the operating system by Apple (again similar to/etc, but in practice there's little of interest in here and nothing that should be tampered with casually, as Apple reserves the right to stomp on this tree during system upgrades)
So in practice, there are two places you'd want to look, one in the home directory, one system-wide. This really isn't that different from how other Unix variants work.
There are a whole lot of annoying idiosyncrasies with OSX, but the file system layout really isn't one of them. Yes, it's much different from how other Unix variants work, but once you get used to it, it's extremely logical, consistent, and predictable; it Makes Sense.
While I can see the advantages of having every app isolated in it's own directory, I feel that one of the things I really like in Linux is to have all configuration in one, relatively small, pure text hierarchy:/etc
OSX has an answer to this as well. By widely accepted convention:
~/Library/Preferences has user-level application settings
/Library/Preferences has system-wide, custom-set application settings
/System/Library/Preferences has system-wide, vendor-set application settings
/etc has settings for the legacy Unix/BSD software
NetInfo has some stuff, but not much anymore...
So this both embraces & extends the/etc config approach, by allowing not only system level (/etc/*) and user level ~/.* configuration areas, but also draws a distinction between system-wide changes that you have made (/Library/* and system-wide settings that were set by Apple with the operating system, and are liable to be superceded by future OS upgrades (/System/Library).
With the Apple approach, if you back up the directories/Library,/Applications, and/Users (and if you've customized things, maybe/usr and/private, which is the true container for/etc,/var, and/tmp), then you're all set.
I can grep [/etc] easily when I look for something, and easily edit the relevant file, which is usually well commented. I cannot grep the entire / tree. Well, I suppose I could, but I certainly don't want to.
The preference files under {~,,/System}/Library/Preferences/* are generally XML formatted, and can be grepped quickly & fairly easily from the command line. In addition, Apple provides the command defaults which can be used to both read & write these XML files -- for example, defaults read com.apple.Safari TabbedBrowsing or defaults write com.apple.Safari TabbedBrowsing 1.
For the rest, grouping all an applications's files together sounds attractive, but I would be happy enough if every app just clearly documented what it did at install time so it's easy to undo.
Vendors that use Apple's package installer end up saving a copy of the installer in/Library/Receipts/*.pkg, under which there will be a *.bom Bill Of Materials file that can be used to find out what an installer added to the system.
* * * * *
So, point for point, OSX has remedies for all your concerns. Happy now?:-)
Make there be two "overlays" for your filesystem. Novice users see all the libs and binaries grouped into a single package. Advanced users can see the real unix hierarchy.
But this is precisely how OSX solves the problem!
In the Finder, which is how novices and people uniterested in system internals will spend most or all of their time, you only see the application (etc) bundles, and the other functionality is hidden from view. Moreover, key system directories (such as/etc,/var, and/usr) are hidden from view by the magic of the/.hidden file, which specifies a list of directories to hide from the Finder.
On the command line, bundles are exposed as the little directory trees that they really are, and you have full access to everything that is masked in the finder by/.hidden.
Moreover, it doesn't make the same, annoying, "where the hell did my shortcuts / files / icons / menu options / etc go???" mistake that recent versions of Windows does. Each view -- the Finder and the command line -- is consistent, predictable, and creates no surprises or mysteries.
For the most part, the OSX approach seems to both solve the problem and also make most everyone happy.
The way OSX bundles functionality in directories isn't really the same as the/opt or/usr/local trees on GNU/Linux or Unix. The latter are places where users can customize a system with their own software, but it's just a housekeeping matter, really.
On OSX, on the other hand, you're actually bundling up functionality in a self-contained wrapper: applications go in.app directories, libraries go in.framework directories, installers go in.pkg directories, etc. These bundles can, in turn, contain other bundles, so for example a.mpkg bundle can installl multiple packages which are also available for installation as separate, atomic entities.
Each bundle has a standard hierarchy, with leaf-nodes for the actual executable file (and any helper code), a separate.nib file or tree for the interface code, localization strings for one or more languages, the icon to display in the Finder, etc.
To the Finder user, this all looks like one monolithic file that can be moved around the filesystem as you like, but from the command line it can all be easily browsed; moreover, you can do things like swap out chunks of the bundle to replace or extend functionality -- for example, you can replace the.nib to change the interface, or you can add or remove localization bundles.
Additionally, there are tools to set these trees up for developers at the start of a project, so all you have to do is fill in the blanks.
In theory, there's even support for including binaries for multiple hardware/software platforms, so for example if OSX were ever ported to x86 hardware (it won't be, but bear with me), the hooks are there to add an MacOS/x86 or even Linux/x86 or Win32/x86 set of executables. And again, to the user, it all just looks like one double-clickable application file in the Finder.
This goes well beyond what the basic/opt tree provides, and it would be a great addition to GNU/Linux or even Windows...
So, out of curiosity, has anyone seen the guts of a Mini-mac yet ? The pictures I've seen on Apple's site -- particularly one of the motherboard and one with the cover removed -- give you some ideas -- compact motherboard, RAM on one side, skinny optical drive on top, mini-speaker in front -- but I'm curious about the hard drive: did they actually jam a full sized IDE drive in there, or is it a compact laptop model or a super-compact iPod one?
Some of the rumor sites were paying slavish attention to the deals Apple was making for bulk purchases of minature hard drives from Asian manufacturers. All of this speculation centered around the possibilities for new iPod models, but it occurs to me that at least some of those drives are probably going into the new Mac as well.
So -- has anyone had a chance to get pictures of a disassembly of a mini Mac yet ?
To my mind, this would not have been as good if [Rogue] was a Canadian accented oriental dwarf (not that there is anything wrong with such a person - but that person is not ROGUE).
Well, that's just it. Most of X-Men's popular characters have well defined backgrounds. To be portrayed convincingly, you'd need an actor that can plausibly appear to have the same background: Nightcrawler would have to look like someone from central Europe (probably white; Storm would have to pass for Egyptian (probably black or Arab), Rogue would have to look like someone from southern Louisiana (probably white, maybe black), and Logan would have to look like someone from northern Canada (probably white, maybe native American).
Other characters don't have as well defined back stories, and could be played by anyone who can get the personality right. None of the original characters -- Jean Grey, Professor X, Scott Summers, and Hank McCoy -- really has a clearly defined background in the same way that the later ones did. While they were all drawn as white people, any of these early characters could be played by a non-white actor.
Note also that casting happens in a broader context: the director is always going to have a limited pool of actors available, and not all of them are going to be perfect fits for characters that the audience is already familiar with (unless you're talking about Harry Potter, in which case pretty much every British actor in the world seems to be willing to take a part). In some cases, the best actor for a part doesn't fit the audience expectations, but can do a good job anyway. For example, in 1990, one of the main parts in Miss Saigon was given to Jonathan Pryce, a white actor, because, in the opinion of the director, he was the best fit for the role. And maybe he was -- he's a fine actor -- but it generated a lot of protests at the time. Whether or not those objections are fair is a subjective matter, depending in part on how much that character's identity depends on ethnicity. If memory serves -- I can't find a URL backing this up, so I may have it wrong, but I'm pretty sure -- a court agreed that it didn't matter, and the show went on.
So it was, a decade later, with X-Men, and now, with Fantastic Four...
The emacs user interface is completely foreign to a Mac environment.
Oh?
Put your cursor in almost any editable text field in your Mac -- the address bar in Safari, any text widgets in a Safari web page, the composition window in Apple Mail, etc -- and try a few Emacs keystrokes.
Huzzah! The Emacs keystrokes work! The beginning & end of a line are [ctrl]+[A] and [ctrl]+[E]; delete-right is [ctrl]+[D], delete-right is [ctrl]+[H]; etc.
Basically any application written in Cocoa -- not the Finder, but most of Apple's other core applications, and a lot of the post-OS9 third party stuff as well -- will get Emacs keybindings by default. If you know Emacs, or learned Emacs keystrokes in another application that uses them (I learned them in Pine and the Bash shell, personally), then you can transfer that finger memory to huge chunks of OSX.
So.... yeah. Emacs out of place on a Mac? Probably not...:-)
Slashdot Mirror
I missed this bit --
Which is a shame, as running both operating systems from time to time can be a useful shift in perspectives, and -- not that this is what Torvalds works on, but regardless -- Linux could do for a vastly improved desktop environment.
Oh well...
I feel so validated right now.
I've been using Linux for a decade now, but dammit there's only so much pain I'm willing to endure from my desktop computer. X11 sucks, and it's holding Linux back. I've given too many hours of my life fighting against arcane config files just so I could get a mouse to work or a display resolution that didn't make my eyes bleed. Never again. I've got more much better things to do than that.
It's nice to see that the leader of the Free world appears to agree :-)
I'm curious to see if this will be a motivator among the groups that have been messing around with a "usable" desktop Linux for years now without actually getting anywhere...
As with anything else, the answers to such questions would depend on who you're asking and what their motivations are, but to hazard some guesses...
Moreover, some ad execs may really believe that users want to see well executed "interference" ads (popups, full screen delays ads, etc_), even if all available evidence suggests otherwise. In the end though, these people need to be able to convince their web publishing partners that popup ads are effective & profitable; this has been true to date, but to keep that claim credible, they can't ignore blockers.
Etc. Different people will have different motivations, but within broad classes like the ones above -- advertising executive, web publisher, technical staff -- I think the motivations above along the right track...
I predict that Randi won't fall for it.
Do I win a million dollars?
The UI is definitely slick, but it definitely has some quirks, some annoying. Some random observations:
Wish list items:
D'oh! Brain fart. Yes, you're right of course...
Guess I need to go watch that movie again :-)
Is this Microsoft's version of David Tufnel's classic "Spinal Tap" bit in which he shows off his special guitar amp that was custom-made for him by Marshall and is better than the regular version, because it goes to eleven.
"The 360 is better, innit? Because, you see, it's 355 more than the N5, and 357 more than the PS3."
All they need are exploding drummers and the circle (ahem) will be complete...
It's been said before, but all generalizations are false.
But aside from most of the facts being against you, it's an interesting point you make :-)
So really, all of this is so distributed and interlocked that it doesn't make much sense to divide them they way you have them, or to assert that there are three source countries each with three primary manufacturers. The reality of the situation is much more involved than that...
It's been a while since I played with it, but my impression was that it was serving different things based on the client IP address, but if all the clients appeared to have the same IP (e.g. different subnets being bridged by a gateway server, so to the SlimServer the clients all appear to be 192.168.0.1 or something) then they'd all get the same stream.
It probably would have been possible to sort it out, but in the end I just got Apache::MP3 working and used that instead. The interface definitely doesn't look as good as SlimServer does, but for the usage model I wanted to support -- coworkers without iTunes (i.e. Linux users using XMMS or whatever, as the Mac & Windows users have & use iTunes) being able to listen to my shared music library via HTTP -- it works well enough.
But SlimServer is definitely a more flexible design, and I really liked the software. If the opportunity comes up to use it again in the future, I look forward to it.
It's not much of a leap to assert that most malware is, on some level, a form of ego tripping, and most malware authors, much like the authors of any other software, would like to see their work spread far and wide.
Hence, antivirus companies always change the name.
Whether or not a virus had a name to begin with, each vendor will select a name of their own for it to deprive the author of that fame. Why encourage them, you know?
But there's the other bit of ego -- each vendor will select a name of their own. For a prominent attack, one of these names will make it into he wider media, and being the vendor that named it is itself an ego boost for that company.
So, all of this naming nonsense is just a stupid dickwaving ego contest. We'd almost be better off if we did like the National Weather Service and named each year's outbreaks in advance, before any of them are spotted in the wild, just to neutralize the stupid games that go on over what this junk gets called. Not that that'll ever happen, of course...
I was looking at this site the other day. My first impression was that it was a pretty good idea -- you have this cheap little computer that would be more than adequate for running a website &/or mail server, and it's small enough that you could get dozens of them of a single rack.
Then it dawned on me that the Mac Mini doesn't have a fan, and depends entirely on being able to vent heat around the bottom edges and back panel. Apple's site has a document warning users:
Sounds like a dense rack full of the things would be liable to overheat & burn out.
Are these people thinking about cooling issues? Their FAQ page made no mention of it last week, and it looks like it still doesn't now. Would anyone trust a rack full of these things not to cook the circuitry?
Just use SlimServer and be done with it. Read about it here, but to repeat the main features:
It's intended to be the interface software for the same company's Squeezebox network audio player, which explains why they're willing to give it away under the GPL -- they make their money of the hardware. That also explains some of the unusual design decisions that went into SlimServer, namely, that unlike some other network streaming setups (Apache::MP3, iTunes DAAP streaming, etc) which let each client listen to their own selections, the SlimServer architecture allows multiple clients to have a say over the one stream that's being used centrally. For a management interface to a central home audio system, or for the system described in this article, that design decision is a perfect fit.
Really, give it a try. I tried setting it up on a LAN for coworkers to listen to mp3s on their headphones, and while everyone liked the interface a lot, it was annoying that everyone listened to the same thing. But if you want to provide a way for everyone to set what is being played on a central system, this is exactly the way to do it.
Of course, if we all move to speaking some kind of ubermetalanguage, that implies that the languages spoken today would be lost. That would be a sad thing.
Language is a reflection of culture, and culture, to date, is a deeply regional thing. The standard example is that the Inuit people of Alaska and Canada have dozens of words for snow; while this seems to be not entirely accurate, the general point stands that different groups have richer or poorer ways of expressing concepts based on their collective experiences. This is both a reflection of and an amplification to regional cultural distinctions.
For an example I'm a bit more confident about, Russian has no word for fun. It's a concept that can more or less be expressed with a string of other words, just as "tsunami" can be expressed in English as a string of other words, but the term itself, and so the concept it represents, isn't directly represented by a Russian word. Funny, eh?
Language is full of these little oddities. One of the great things about English is the tendency to gladly pick up terms from other languages when we can't express something already -- cf. "tsunami". If everyone were to speak one doubleplusgooduberlanguage, then this ability to cross-pollinte will presumably go away. That would be doubleplusungood.
But I don't think we're in any danger of that. English may be becoming a "world language", sure, but look at all the regional variations: it can be a real stretch to assume that the Hindi inflected English in India, the Chinese inflected language in Hong Kong & Singapore, the hodgepodge of influences on dialects in the Caribbean, and the diverse variants spoken in the UK, USA, and Australia are really all the "same" language. In a lot of ways, these dialects of English are only growing farther apart, just as the French spoken in places like Haiti and Cote d'Ivorie are much different from the language in France, and the German spoken in Switzerland is much different from the Hochdeutsch in Germany.
You could argue that the Internet may bring all these streams of language closer together, but you could just as credibly argue that it will only serve to churn the already turbulent patterns that are driving languages apart.
Personally, my hunch is that while some kind of pidgin English may come to be widely understood around the world, the predominant trend is going to be increased, not decreased, diversity in global language patterns. And I see that as nothing but a good thing.
As I say, I don't know Lisp, I've never coded in it (before 5 minutes ago when I started this post), and I'm not sure how Lisp/Scheme syntax usually captures things like XML attributes, or name/value pairs, etc. But come on, this is on the right track, isn't it? And isn't it waaaay easier to read and understand than the XML version?
If XML is proof of anything, it's that the MIT hackers were right decades ago when they started out trying to win the world over to Lisp. All XML is, is ridiculously verbose Lisp, right?
The article reads, in full:
While it's good to see that le gendarmerie are going to be switching over to everyone's favorite underdog office suite, I don't see where this is the same thing as them all moving to Linux as well. Did a longer version of the article throw in that detail, or was the submitter or the editor getting carried away here?
The $PATH variable works in the usual sense on the command line -- it typically looks for commands in places like /bin, /usr/bin, /usr/local/bin, ~/bin, etc -- but it doesn't appear to be relevant to the GUI, or to the open command which can be used to open files in the GUI (e.g. open -a Safari ~/Sites/index.html).
As near as I can tell, /Applications is the GUI analogue to */bin directories, and the Finder is just transparently aware of everything under there. If you want to launch a graphical application from the command line, you either invoke it with the open command as noted above, or you invoke it directly as, for example, with the Vim GUI:
Meanwhile, in the Finder, all you see in this example is a folder vim under the Applications folder, in which (among a couple of other things I have in the same folder with Vim.app) is a single double-clickable application "Vim" with the usual green logo icon. The structure underneath is not at all apparent from this view.
I think the way to get this done on Linux would be to extend one of the graphical frameworks -- GNUStep / WindowMaker would be a good candidate -- to have the same bifurcated view that you get between the Aqua GUI and the command line on OSX. I don't know much about GNUStep, but it's possible that it already provides much of what would be needed to do all this...
For values of "shitload" where "shitload" equals "three", yeah.
So in practice, there are two places you'd want to look, one in the home directory, one system-wide. This really isn't that different from how other Unix variants work.
There are a whole lot of annoying idiosyncrasies with OSX, but the file system layout really isn't one of them. Yes, it's much different from how other Unix variants work, but once you get used to it, it's extremely logical, consistent, and predictable; it Makes Sense.
OSX has an answer to this as well. By widely accepted convention:
So this both embraces & extends the /etc config approach, by allowing not only system level (/etc/*) and user level ~/.* configuration areas, but also draws a distinction between system-wide changes that you have made (/Library/* and system-wide settings that were set by Apple with the operating system, and are liable to be superceded by future OS upgrades (/System/Library).
With the Apple approach, if you back up the directories /Library, /Applications, and /Users (and if you've customized things, maybe /usr and /private, which is the true container for /etc, /var, and /tmp), then you're all set.
The preference files under {~,,/System}/Library/Preferences/* are generally XML formatted, and can be grepped quickly & fairly easily from the command line. In addition, Apple provides the command defaults which can be used to both read & write these XML files -- for example, defaults read com.apple.Safari TabbedBrowsing or defaults write com.apple.Safari TabbedBrowsing 1.
Vendors that use Apple's package installer end up saving a copy of the installer in /Library/Receipts/*.pkg, under which there will be a *.bom Bill Of Materials file that can be used to find out what an installer added to the system.
* * * * *
So, point for point, OSX has remedies for all your concerns. Happy now? :-)
But this is precisely how OSX solves the problem!
In the Finder, which is how novices and people uniterested in system internals will spend most or all of their time, you only see the application (etc) bundles, and the other functionality is hidden from view. Moreover, key system directories (such as /etc, /var, and /usr) are hidden from view by the magic of the /.hidden file, which specifies a list of directories to hide from the Finder.
On the command line, bundles are exposed as the little directory trees that they really are, and you have full access to everything that is masked in the finder by /.hidden.
Moreover, it doesn't make the same, annoying, "where the hell did my shortcuts / files / icons / menu options / etc go???" mistake that recent versions of Windows does. Each view -- the Finder and the command line -- is consistent, predictable, and creates no surprises or mysteries.
For the most part, the OSX approach seems to both solve the problem and also make most everyone happy.
On OSX, on the other hand, you're actually bundling up functionality in a self-contained wrapper: applications go in .app directories, libraries go in .framework directories, installers go in .pkg directories, etc. These bundles can, in turn, contain other bundles, so for example a .mpkg bundle can installl multiple packages which are also available for installation as separate, atomic entities.
Each bundle has a standard hierarchy, with leaf-nodes for the actual executable file (and any helper code), a separate .nib file or tree for the interface code, localization strings for one or more languages, the icon to display in the Finder, etc.
To the Finder user, this all looks like one monolithic file that can be moved around the filesystem as you like, but from the command line it can all be easily browsed; moreover, you can do things like swap out chunks of the bundle to replace or extend functionality -- for example, you can replace the .nib to change the interface, or you can add or remove localization bundles.
Additionally, there are tools to set these trees up for developers at the start of a project, so all you have to do is fill in the blanks.
In theory, there's even support for including binaries for multiple hardware/software platforms, so for example if OSX were ever ported to x86 hardware (it won't be, but bear with me), the hooks are there to add an MacOS/x86 or even Linux/x86 or Win32/x86 set of executables. And again, to the user, it all just looks like one double-clickable application file in the Finder.
This goes well beyond what the basic /opt tree provides, and it would be a great addition to GNU/Linux or even Windows...
So, out of curiosity, has anyone seen the guts of a Mini-mac yet ? The pictures I've seen on Apple's site -- particularly one of the motherboard and one with the cover removed -- give you some ideas -- compact motherboard, RAM on one side, skinny optical drive on top, mini-speaker in front -- but I'm curious about the hard drive: did they actually jam a full sized IDE drive in there, or is it a compact laptop model or a super-compact iPod one?
Some of the rumor sites were paying slavish attention to the deals Apple was making for bulk purchases of minature hard drives from Asian manufacturers. All of this speculation centered around the possibilities for new iPod models, but it occurs to me that at least some of those drives are probably going into the new Mac as well.
So -- has anyone had a chance to get pictures of a disassembly of a mini Mac yet ?
Well, that's just it. Most of X-Men's popular characters have well defined backgrounds. To be portrayed convincingly, you'd need an actor that can plausibly appear to have the same background: Nightcrawler would have to look like someone from central Europe (probably white; Storm would have to pass for Egyptian (probably black or Arab), Rogue would have to look like someone from southern Louisiana (probably white, maybe black), and Logan would have to look like someone from northern Canada (probably white, maybe native American).
Other characters don't have as well defined back stories, and could be played by anyone who can get the personality right. None of the original characters -- Jean Grey, Professor X, Scott Summers, and Hank McCoy -- really has a clearly defined background in the same way that the later ones did. While they were all drawn as white people, any of these early characters could be played by a non-white actor.
Note also that casting happens in a broader context: the director is always going to have a limited pool of actors available, and not all of them are going to be perfect fits for characters that the audience is already familiar with (unless you're talking about Harry Potter, in which case pretty much every British actor in the world seems to be willing to take a part). In some cases, the best actor for a part doesn't fit the audience expectations, but can do a good job anyway. For example, in 1990, one of the main parts in Miss Saigon was given to Jonathan Pryce, a white actor, because, in the opinion of the director, he was the best fit for the role. And maybe he was -- he's a fine actor -- but it generated a lot of protests at the time. Whether or not those objections are fair is a subjective matter, depending in part on how much that character's identity depends on ethnicity. If memory serves -- I can't find a URL backing this up, so I may have it wrong, but I'm pretty sure -- a court agreed that it didn't matter, and the show went on.
So it was, a decade later, with X-Men, and now, with Fantastic Four...
Yes. Clearly you should have been thinking of punk bands, not software :-)
Oh?
Put your cursor in almost any editable text field in your Mac -- the address bar in Safari, any text widgets in a Safari web page, the composition window in Apple Mail, etc -- and try a few Emacs keystrokes.
Huzzah! The Emacs keystrokes work! The beginning & end of a line are [ctrl]+[A] and [ctrl]+[E]; delete-right is [ctrl]+[D], delete-right is [ctrl]+[H]; etc.
Basically any application written in Cocoa -- not the Finder, but most of Apple's other core applications, and a lot of the post-OS9 third party stuff as well -- will get Emacs keybindings by default. If you know Emacs, or learned Emacs keystrokes in another application that uses them (I learned them in Pine and the Bash shell, personally), then you can transfer that finger memory to huge chunks of OSX.
So.... yeah. Emacs out of place on a Mac? Probably not... :-)