161–170 of 217 posts
Earlier quoted context omitted.
At Microsoft, if there is a design choice between "abandon the old user" or "let's forget them to make the current product better," they nearly always choose #1. Apple nearly always chooses #2. (I still remember DOS 3.2 to DOS 3.3.)
You probably meant "support the old users", otherwise your two options are pretty much the same :)
Earlier quoted context omitted.
Files are data. Data should be eternal. You should be able to convert a presentation you make today 30 years from now to a newer format. Making software not-backwards compatible is fine and normal but if files expire in a few years Apple is saying that the things you do on their computers are disposable.
"Data should be eternal." This is not a useful statement. If you convert the "should" to a "shall", and try to design a system around that requirement alone, it would prove very hard. Even designing a clock around that requirement is very hard ( http://longnow.org/clock/ ). If you back off from the "shall", then you are in the standard world of engineering tradeoffs, which is where you started. What features do you w…
Earlier quoted context omitted.
#2 isn't viable because it breaks the primary design goal and the entire purpose of Keynote '13--that every presentation opens the same way across desktop, web, and mobile. The Keynote '09 source code does not and never has compiled for ARM, and so you would be faced with exactly the same dialog you have now, except instead of on your Mac it's on your iPad and instead of asking you to find an old version of keynote i…
Somehow Apple has been able to port their entire operating system from PPC to Intel to ARM. I think they could manage porting a bit of iWork code.
Source is plain ASCII. Output is PDF. Interpreter is TeX. All three are very, very robust for backward compatibility.
That Microsoft is being promoted for backwards (and forwards) compatibility strikes me as ... comical.
Earlier quoted context omitted.
If I were Apple, right now I'd be more concerned with losing customers to Android devices. Case in point: we have an iPad here that is still on the iOS 5 generation it came with. It has been widely reported that iOS 6 was slower (as well as breaking things like Google Maps), iOS 7 was slower still (as well as making various visual styling changes we don't like) and both iOS 6 and iOS 7 have suffered at least one seve…
It is a good point and I agree with you it can be annoying to be forced to upgrade perfectly good software. But it does cut both ways. Legacy support is generally good for customers, but a burden for developers. As far as development and having to spend money on hardware, though, I'd say Android is far worse than Apple in that regard. Android still has nearly half of devices running 2.x and the screen sizes are all o…
I think it is deeply regrettable that certain parts of the industry have moved in that direction, and Android is a fine example (as is almost anything else Google makes). That said, it's still preferable to Apple, who move fast, break stuff, and then won't even let you fix it by moving back again.
Earlier quoted context omitted.
There's no formatting info in those. Why not just include a statically linked copy of xpdf? The x86 family will be around for a while, and if it goes away I'm sure there will be emulators.
What do you do when xpdf doesn't display the pdf correctly? What system does that statically linked thing run on? Is that system going to remain compatible for decades? Or emulators capable of running an old version of it? Why overcomplicate matters when you can pick something you know just works.
I'm just not especially concerned. It's not like I get better life out of my paper documents, as I don't worry about the whole acid-free paper in an hermetic container deal.
In 2013, documents are STILL being produced into a proprietary format that nothing open source can read (directly) a decade later.
This is why I love Python and Perl for data munging.
Earlier quoted context omitted.
"Patches welcome" is an aggressive, user-hostile, anti-social response to being told that the thing you suggested does not work . It's telling the user to fuck off because your own suggestion was flawed. clarry didn't run to HN and scream "pdf.js sucks!".
No, it isn't. It's the whole point of FOSS. If it doesn't work for you, fix it. This criticism is especially off-base given that the OP said he wanted something he could control. Use the source, Luke!
"I'd rather bet on something you can implement all by yourself without needing to wade through a thousand page spec."
pdf.js was obviously outside the bounds of what he said he wanted from the beginning. You stubbornly brought it up anyway, then gave a nasty, clichéd response when he pointed out exactly why it was the wrong answer.
"If it doesn't work for you, fix it" is ridiculous. It's saying "here's this thing that doesn't do what you want, go make it do what you want instead of using these other things that already do what you want".
Earlier quoted context omitted.
The problem with airgap test equipment (I work on this kinda of stuff professionally). Is often the redevelopment of real time software for lab and calibration equipment is very expensive. Its easy to think, "Why don't they use [New Hotness Software ]?" Which on the surface seems to be a good idea. Until you absolutely need sub-millisecond precision I/O, then you kinda start to cry when you realize how hard precise t…
It would be so nice if programs could request a dedicated core for these kinds of things.
You can extend this further by doing things like mmaping in 4GB of memory through the kernels hugepage support and lock the physical to virtual address map so the kernel can't touch your physical block of ram you just allocated. Then you can do things like talk directly to a pci device like a network card and set up DMA directly from a NIC into a buffer in your applications memory.
All of this is done completely in userspace but you get all the performance benefits of implementing everything like it was running in Ring 0 and the kernel is not involved in anything apart from the initial setup and teardown. You can build an extremely high performance application basically running on bare metal but with the Linux kernel still running on a different core to handle anything that doesn't directly involve your application and there wouldn't need to be any syscalls between the two to service some request.