Forgot your password?
typodupeerror

Comment: Re:Supplant 32-bit ABI (Score 1) 262

by AReilly (#45780101) Attached to: Linux x32 ABI Not Catching Wind

This.

With a slight caveat that in that last one percent is probably the use case of DOM inside a browser page looks sufficiently like an irreducible thicket of tiny objects, and still wants all the speed that it can get, which is why Google is pushing x32 for Chrome plugins. Maybe it helps a bit for Javascript compilation too.

At least if your x32 is (a) sandboxed in a browser process and (b) generated by a JIT then the library duplication badness should be negligible and the result mostly invisible to the user.

For my own code, I wouldn't touch it with a bargepole. Storing pointers in memory? Madness...

Comment: Re:Then make gestures with the keyboard (Score 1) 414

by AReilly (#45117875) Attached to: Shuttleworth: Apple Will Merge Mac and iPhone

You've seen a lot of applications that work like that?

Sure it might be feasible. Might even happen, one day. Isn't the case now though, and I think that you're radically under-estimating the amount of re-work (basically re-design) that would be required to have fully-useful two-mode applications.

There are some, I suppose. Apple's got versions of Pages and their other iWork applications that run in desktop and tablet mode. So they're probably ahead of the game as far as useful convergence is concerned.

Comment: Re: But unlike Android apps (Score 2) 107

by AReilly (#44326021) Attached to: Study Finds iOS Apps Just As Intrusive As Android Apps

Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.

It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.

Comment: Re:Windows 8 rocks (Score 1) 965

by AReilly (#43166919) Attached to: Ask Slashdot: Mac To Linux Return Flow?

How can a task manager be "mind blowingly awesome"? Having to use a task manager at all is a fairly sure sign that things are not going well. That they've made that some sort of central feature is, IMO, a bit worrying.

Similarly: I've never used a platform other than windows where the act of copying or moving files around in the filesystem was so painful, or where there could be a reasonable cause to pretty up the dialog enough that you'd notice it. Everywhere else moves are normally instantaneous (unless to other filesystems) and copies are just copies. Yes, I am not a fan of MacOS asking whether you want to overwrite target files either: Unix had this right in the first place: unless it's locked down, in which case the action is failed, if I say I want to copy that over there, then that's what I want to happen. If I make a mistake I can jolly well recover from backup, or run around screaming.

Comment: Re:What doesn't work? (Score 1) 965

by AReilly (#43166849) Attached to: Ask Slashdot: Mac To Linux Return Flow?

I switched to MacOS from FreeBSD a few years ago because using appropriate proprietary graphics drivers weren't an issue (and always will be an issue on FreeBSD, as far as I can see), and because I wanted to use Lightroom for my photography hobby. That's all, but they're two things that I can't see changing any time soon. Switching to windows wouldn't have worked, because although I want those two specific features, I don't want to lose my comfy BSD/Posix command line environment. The windows command line experience has been astonishingly awful for its entire existence, so it is not something I can expect to change any time soon. I don't think that Ubuntu is in a measurably different position to FreeBSD in this.

Comment: Re:Could you tell me more about the iOS-ification? (Score 1) 965

by AReilly (#43166305) Attached to: Ask Slashdot: Mac To Linux Return Flow?

Most of the whinging seems to centre around the existence of an app-store (which, as someone who uses FreeBSD ports and apt-get on a regular basis is simply a good idea, not something to be afraid of) and the (optional) removal of permanently-visible scroll-bars in favour of multi-touch swiping on the track-pad (or mouse-wheel, I suppose.) I count both of them improvements, but clearly tastes differ.

Real iOS-ification would be sandboxing applications so that they can't operate on arbitrary files in the file system, and removal of access to said file-system. I can't really see either of those happening.

Personally, I can see where the tea-leaves are pointing, and am in the progress of moving all of my daily activity into a personal "cloud" hosted on my own FreeBSD box. Then I can use osx or android or whatever has the good proprietary graphics stack at the time and just get on with it.

Comment: Re:Intel always rules high performance computing (Score 1) 605

by AReilly (#43089105) Attached to: Why Can't Intel Kill x86?

I think that you'll find that a fair chunk of the top-end of the top500 (and the graph500) are IBM Blue-something systems that run variants of Power. These are essentially descendants of the PowerPC440 series of embedded processors: not terribly fierce on their own, but have a significant advantage for this sort of work: they don't consume much power. So you can run a *lot* of them with a limited power budget. Much like ARM, which is why several folk, including AMD, are lining up to do server versions of AArch64.

Which is why Facebook and others have created the Open Server Aliance, and why Intel, AMD and ARM are all members, and are all producing CPU+memory modules to suit that space.

Low power devices are the present and the future, even if you need the power supply of a medium-sized town to run the data-centre.

Comment: Re:Isn't it time to trim FAT? (Score 1) 272

by AReilly (#42992461) Attached to: Nikon Buckles To Microsoft, Will Pay "Android Tax" For Smart Cameras

The patents and the compatibility in question relate specifically to the way Microsoft encoded the long-file-name compatibility, and the short-form-contraction extensions into the FAT directory structure. It's an ugly hack that no-one with skill in the art would think of doing, so it's a legitimate patent. I don't know why camera makers don't just limit themselves to the 8.3 filename space and avoid even dealing with long file names: every camera I know of seems to work like that anyway.

The primary work-around du-jour (and it's a good one) is USB-PTP protocol (and variants) that avoid the question by not exposing the block device structure at all: operate more like a network file system. Makes perfect sense. This is why lots of mobile devices don't have SD card slots. Add an SD card slot and you have to support FAT or exFAT. Leave the slot out and you can run ext2 or whatever on your internal flash drive, and expose files to the external world over wifi or USB-PTP.

Since the controllers in SD cards are computers too, it would probably be feasible to build some sort of SD card variant that spoke PTP directly, but how likely is that?

Comment: Native framework not-quite-C++ yay. (Score 2) 37

by AReilly (#42952629) Attached to: Tizen 2.0 Magnolia SDK and Source Code Released

I read a little of the on-line doco, and noticed that the "native development" system supports C++ but not exceptions. So two-phase object initialisation is a requirement and try/except is out, and a bunch of standard APIs can't be used. There was also something about restrictions on C use, should you prefer that, but also missing some standard library functions. That's not too surprising, but I suspect that the C++ restriction is going to make porting code from existing sources painful. I dimly remember C++ under Symbian being odd, for similar reasons. Maybe for exactly the same reasons and with the same heritage?

Comment: Re:Underlying structure versus pretty pictures. (Score 1) 320

by AReilly (#42939823) Attached to: Why Hasn't 3D Taken Off For the Web?

NeXT wasn't the only, or even the first OS that had vector graphics baked in at a low level. Acorn's RiscOS was all vector graphics and scalable, anti-aliased fonts from the late '80s on, on a 4MHz processor that had no cache and a dumb frame buffer in bandwidth-sucking "shared DRAM". True, it didn't have much in the way of actual resolution either, but it did work very well. Performance of the vector drawing primitives was never a big issue. That was a machine that was in the same ballpark as the IBM PC-XT (which was a contemporary), price-wise.

Comment: Re:I can see it. (Score 1) 66

by AReilly (#42527939) Attached to: Tablet Shipments Will Finally Overtake Notebooks In 2013

That's not it at all: tablets are now (or will be soon) just "screens": no different from the one in your lounge room or on front of the fridge. The circuits are just moving around a bit. If you want to *do* something with it, you'll be able to use that box with the hard drives and the peripherals sitting in the corner of your office just as easily as you can now, or you can rent space on someone's cloud server, if you prefer.

Don't think of it as losing your PC. It's more the case that your laptop/desktop monitor can still do a range of useful things after the "PC" has been powered down. There are already plenty of manufacturers who have the clue, and are selling WiFi enabled network hard drives: "personal cloud" systems.

Comment: Re:Why do we need a desktop client? (Score 1) 464

by AReilly (#42232669) Attached to: Ask Slashdot: Current State of Linux Email Clients?

No, Outlook with Exchange is terrible on many levels. Probably Exchange's fault, and the fact that it doesn't use IMAP. Every time I have to fire the beast up for some reason, it takes more than half an hour to "synch" to my mailbox. How is that even possible over gigabit ethernet? Why, every time? Does it forget everything it ever synched the last time? Rubbish.

Comment: Re:Why do we need a desktop client? (Score 1) 464

by AReilly (#42232657) Attached to: Ask Slashdot: Current State of Linux Email Clients?

Non-braindamaged message composition, sane integration with the rest of the native applications that I use, off-line access, seamless integration of multiple accounts and, oh, speed. Built-in searching, and integration with the platform's native searching are bonuses. Oh, and not being in a web browser.

BTW: Mail.app has some faults, but as an IMAP client (with dovecot back-end) I've met nothing that comes close. (OK, claws-mail is fairly close, but lack of html/rich-text composition is limiting in some contexts.) I would *love* to have something as good as Mail.app on Linux/FreeBSD.

Suburbia is where the developer bulldozes out the trees, then names the streets after them. -- Bill Vaughn

Working...