MagerValp

As a bare minimum Apple needs a few hours to analyze the bug, and if the fix is straightforward and doesn't cause any regressions the QA process can begin. Getting the it out to the general public in less than a week is extremely unlikely, and that's provided that they deem it critical enough for an emergency patch (my guess is no). Otherwise we're going to be vulnerable until 10.10.6 and security update 2015-007.

Malware already preys on those least capable of defending themselves, so an unsigned 3rd party kext or a performance degrading boot option does nothing to protect them. We have no indication that this was being exploited by anyone else, if they were that would be newsworthy in itself.

I like your idea of releasing an unofficial patch instead of exploit code though. I still think that you should follow the established responsible disclosure process, but it would at least show some interest in helping users. Oh, and don't be a dick and release it on a Saturday afternoon.

Malware comes precompiled and ready to run, it doesn't depend on you having a compiler installed.

The DYLD_PRINT_TO_FILE exploit was fixed in 10.10.5.

Are you talking about his comment about -no_shared_cr3, which causes a noticable performance degradation, and how he will be releasing a kext soon - neither of which is mentioned in the github readme, but buried in HN comments? A small portion of users might be considered vigilant, but they're not psychic.

The largest target for local privesc are the people who get hit by different kinds of malware, usually as a payload in sleazy spyware installers. The malware authors now have a few profitable weeks before Apple patches it (here's hoping they're quick!) and only the elite few who know how to deploy an unsigned kext (that still isn't available) will be able to protect themselves.

Still not seeing the upside to this.

Apple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after.

I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even trying is just irresponsible. There's a lot of room for improvement in Apple's handling of vulnerabilities, especially with regards to response time and proactive work, but I don't see how deliberately waiting until 10.10.5 and then releasing a 0-day is helping anyone.

It's interesting that the OS has actually aged pretty well. I went back the other year and wrote a small application in AmigaE, a great little OO language specifically tailored for the M68k, and had a blast. I architectured it to use multiple processes and IPC, with the UI running at high priority at a steady 60 fps while image loading a decoding is done in the background. No assembly code or direct hardware access, just plain E and the full OS multitasking int he background, and it still runs without dropping a frame on a 7 MHz A500 with a floppy drive.

The code is on Github if anyone's curious:

  https://github.com/MagerValp/ArcadeGameSelector

Couldn't agree more, his videos are extremely detailed and very easy to follow! I followed his A4000 audio repair video and managed to fix all the problems with my board.

Both of which seem like a valid strategy to me. The OS has never guaranteed that a particular URL scheme goes to a particular app, and developers are wrong to assume that it goes to their app and not someone else's. I realize that there aren't that many alternatives on iOS, but a sharing extension at least gives the user complete control. On OS X there are a wealth of different IPC options, including sockets and mach based services.

It would of course be nice if Apple provided a nice GUI to control the Launch Services database, but since they haven't you have to assume that users are neither in control nor aware of which app handles which URL scheme.

That paper is rife with confusing or just plain wrong terminology, and the discussion jumps between Android, iOS, and OS X, making it really hard to digest. I think these are the bugs they have discovered, but if anyone could clarify that would be great:

• The keychain can be compromised by a malicious app that plants poisoned entires for other apps, which when they store entries that should be private end up readable by the malicious app.

• A malicious app can contain helper apps, and Apple fails to ensure that the helper app has a unique bundle ID, giving it access to another app's sandbox.

• WebSockets are unauthenticated. This seems to be by design rather than a bug though, and applications would presumably authenticate clients themselves, or am I missing something?

• URL schemes are unauthenticated, again as far as I can tell by design, and not a channel where you'd normally send sensitive data.

Yes, though few 8-bit CPUs supported 16-bit arithmetic. Most required two 8-bit operations with carry instead, an din that case there's no difference between little and big endianness - in both cases the LSB has to be calculated first.

The big endian 6809 supports 16-bit arithmetic, and is indeed punished for it: 16-bit ADD and SUB costs an extra cycle compared to a little endian design.

It's fascinating how many great stories there are from this wild west period of the computer industry, thanks for a great writeup.

I have to pick a nit with footnote 10 though, "There's no need for a processor accessing bits in parallel to be little endian" – there is when your data bus is narrower than the address bus, such as an 8-bit CPU performing indexed or relative 16-bit addressing. The simple pipelining of the little endian 6502 allows it to calculate the lower half of the target address while it fetches the upper half from memory, saving a cycle compared to the big endian 6800.

BSDPy, AutoNBI, and Imagr provides a bleeding edge OS X deployment solution that runs entirely on Linux. OS images can be generated with AutoDMG, and Munki will keep them configured and updated afterwards.

Pop into ##osx-server on freenode if you want to talk to the devs.

Portal, like many new-ish 3D games, have a very narrow FOV (in the 60-75 degree range) compared to classic 3D games (90-100). If you have a widescreen monitor (which amazingly wasn't standard when HL2 and Portal were released) try cl_fov 110 in the console.

25 years experience helps a lot, there are much better tools available (cross-assemblers, editors, make, git), and there's a wealth of documentation that just wasn't available back then.

The edit-compile-test cycle is near instant and debugging from an emulator is a lot easier than debugging on the real hardware.

When I fall in love with a personal project, it happens to me too. The important factor is that I don't have anyone else to explain myself to, no one blocking my changes, I own the whole project from the bottom all the way to the top - it's basically just a giant positive feedback loop.

I checked my stats and over the last six weeks I have dedicated my spare time (of which there has been more than usual, but I have a family and work 9-5) to my current project, and I've averaged 7 commits per day with 59308 lines added, 22903 deleted.

I am feeling a little burnt out now, but fortunately the code is essentially done and all that's left is a little mop up and writing a blog post.

I agree that the gendering sucks, but I'll say that the Lego Friends sets are a great match with the Castle sets. Banquets, anyone?

Yes, BASIC 3.5 (264 machines) and BASIC 7.0 (C128) were further developments, as well as the unreleased 3.6 (LCD) and 10.0 (C65): http://en.wikipedia.org/wiki/Commodore_BASIC#Released_versio...

AmigaBASIC was indeed a bit of a lame duck. I used HiSoft BASIC myself, which was backwards compatible but added a lot of features, including a compiler.

Commodore famously licensed Microsoft BASIC on a "pay once, no royalties" basis, and independently kept developing it for its 8-bit line of computers. If you're interested in its history David Viner has posted the source for version 4.75 from 1982 with several enhancements:

http://www.davidviner.com/cbm9.html

10.10 ships launchd 2.0 which is a complete rewrite: https://twitter.com/launchderp/status/528053818156527616

Apparently the launchd code got rolled into xpc, which is closed source.

Would you actually notice a single dead subpixel though at that resolution?

Not sure about the other countries, but in Sweden it's $11/month (79 kr). Netflix is also 79 kr/month, and the (in practice) mandatory TV license which pays for (awesome!) public service is roughly twice as much at 173 kr/month. All have decent streaming services which covers the devices I care about.

There is very little reason to pirate TV in Sweden today, I think the only major shows you can't get are AMC's.

The update package itself is signed.

Interestingly this popped up in my RSS feed as I'm watching Sal Soghoian present what's new in 10.10 automation at http://macsysadmin.se/

No better way to learn than straight from the person who's responsible.

I've used them all to good effect, but I don't think it's fair to call them similar to Gooey. They require a bit of tinkering to work and your script has to adapt to running with a GUI. Zero effort to turn your ArgumentParser into a GUI is really a brilliant feature.

I just want to second this, I didn't fully understand networking until I wrote my own stack and threw packets on the wire. A simple stack with ARP/ICMP/IP/UDP can be written in a day and seeing your very own ping packets fly across the globe is pretty damn awesome.

1 MHz, and while I only implemented UDP in my stack (https://github.com/oliverschmidt/ip65), Jonno Downes took over and added TCP later. There's also Adam Dunkels uIP and Doc Bacardi's HTTP-Load.

So yes, if a C64 can handle it Python should have plenty of power.

Since Amit's apparently here reading, great job on updating your A* introduction (which was already excellent!), I really like how you break it down piece by piece. While it's a very simple algorithm at its core, there are some really subtle nuances that are easy to miss when you first approach it, e.g. the difference between a search node and a map coordinate (assuming classic 2D game maps).

I had some fun earlier this year implementing A* in 6502 assembler, starting with Python and working my way down through Objective-C and C before finally hand-optimizing the critical paths in asm. Articles are here for those who enjoy that kind of thing:

http://magervalp.github.io/2014/05/02/priority-queue-in-asm.... http://magervalp.github.io/2014/05/07/astar-in-asm.html

The code is available on github too: https://github.com/MagerValp/AsmAstar

The font rendering in Atom is what's currently keeping me from giving it a serious try:

http://discuss.atom.io/t/atom-vs-textmate-font-rendering/907...

I think you have a third party OpenSSL installed. On an unmodified 10.9.2 you get:

    $ sw_vers
    ProductName:	Mac OS X
    ProductVersion:	10.9.2
    BuildVersion:	13C64
    $ openssl version
    OpenSSL 0.9.8y 5 Feb 2013

I don't think it's particularly fair to lump Apple with the rest since 14 years later [1] the core OS is still open source [2], and they're actively working on several high profile open source projects (e.g. Webkit, CUPS, and clang). They're not exactly irrelevant either.

[1] http://www.apple.com/pr/library/2000/04/05Apple-Releases-Dar... [2] http://opensource.apple.com/