Fuchsia: a new operating system - <AUTHOR> https://lwn.net/SubscriberLink/718267/206c8a5fbf0ee2ea/ <comment><USER2> What makes Fuchsia different then so many other attempts at writing a new OS? They aren't writing a new OS, at least, not in the complete sense.

They are using the IPC system developed in and extracted from Chrome. They are drawing everything in userspace with fast graphics render but the logic for all system components written in Dart from the Flutter project. They use musl for the libc. They are using the little kernel for the core kernel.

As a long time Linux desktop user myself, I'm really excited about this project. A secure desktop without tons of system calls? Userspace graphics? Not HTML/JS based? But could still be used for development? Yes Please!

It's really easy to compile and get it running. Try it out!

<comment><USER3> >They are drawing everything in userspace with fast graphics render...

Dumb question, does this mean that it's limited to software rendering only? You need to go through the kernel to talk to the GPU, right?

<comment><USER4> No. GPUs typically work over the PCIE bus, and one can talk to PCIE via user space as well. In legacy systems like Linux the mapping of virtual to physical address and generation of scatter-gather-lists (SGLs) resided in the kernel. If one moves the same functionality to the user space without loss in performance (which is what magenta seems to do), there's no benefit to kernel GPU drivers.

Then there's the whole "GPL mafia" in the Linux world who'd like to force vendors to open up their drivers by moving as much of the critical pieces to the kernel as possible. In theory, you cannot write a kernel driver without violating the GPL. Fuchsia will have no such impositions. If someone wants to open their driver up, they could. If they believe their offering is superior, and a secret sauce needs protecting, they can keep it closed

<comment><USER5> You make open source drivers sound like a bad thing.

<comment><USER4> offering no alternative but "open source" on Linux is certainly not the most business friendly way to go about it.

<comment><USER6> Being business-friendly is not a goal, and shouldn't be a goal.

<comment><USER7> > Being business-friendly is not a goal

Sure, it is, for lots of people. Even, apparently, the FSF, hence the reason non-consumer products are _not_ subject to anti-tivoization rules in GPLv3.

<comment><USER8> I wonder why the BSDs haven't caught on for embedded appliances and phones while Linux did with a more restrictive and less business friendly license. Sure some companies like iXSystems and Juniper adopted BSDs, but the vast majority used Linux.

<comment><USER9> The manpower behind Linux is superior. Not sure if it's the "vast majority", but for many business cases following the GPL(v2) rules simply is not a problem.

Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.

<comment><USER10> >Both the PS4 and the Nintendo Switch run on FreeBSD, by the way.

Not exactly from what I've read, the PS4 runs 'Orbis OS' which is based upon FreeBSD 9, meanwhile the Nintendo Switch is using the network stack from FreeBSD, but also stuff from Android and the custom OS they wrote for 3DS.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Capability-based operating systems must be the future. If they are not, then we are all doomed to continue to exist in a messy world where security problems crop up every minute. Capability-based access controls are one of the best options for getting out of our current mess, but they're also the type of thing that must be implemented very low in the system in order to work.

Hopefully, when we start ripping out *nix before 2038, Fuscia and other capability-based OS's can take over.

<comment><USER12> > If they are not, then we are all doomed to continue to exist in a messy > world where security problems crop up every minute.

Side-tangent, but security enthusiasts need to calm down on the "world is ending" talk. Those of us who lived through Windows ME, where logging on IRC basically gave you a 25% chance of having your computer hijacked by some random script kiddie, think it's laughable to say that security is anywhere _near_ as bad as it used to be. Night and day.

<comment><USER13> > Those of us who lived through Windows ME, where logging on IRC basically > gave you a 25% chance of having your computer hijacked by some random script > kiddie, think it's laughable to say that security is anywhere near as bad as > it used to be. Night and day.

Those were people just messing around. Annoying and harmful to your local machine certainly, but the harm that was caused was localized.

Security vulnerabilities are now industrialized, with large-scale public attacks and widespread silent compromises used to gather and sell your information for profit. The situation is still bad, it's just bad in a different way.

<comment><USER14> Individually, computers today are more secure than they've ever been.

But there are zillions more computers, doing more things, with more interconnections than ever before. So the problems are compounded and I think the situation is worse overall.

<comment><USER15> > * Individually, computers today are more secure than they've ever been.*

Unfortunately, that only holds if you take the view that IoT appliance != computer.

Because let's be honest - those things are _dangerous_ to general network hygiene and wellbeing.

<comment><USER14> True, IoT devices are less secure than their internetless predecessors. But they're more secure than Windows 95 computers.

</comment></comment></comment></comment></comment></comment><comment><USER16> I've been waiting for this to be released. I suppose everyone has been.

 _Capabilities_. Like fine grain locks, these are very powerful and very hard to get right. That's the lesson from Hydra, the 432, .... No, it's not a hard mechanism for the microkernel to get right; it's a hard policy for the application programmer to get right. However, that's probably more of an _opportunity_ rather than meant as a criticism. Our tools are massively more evolved than they were in the 70s. It'll be interesting to see what happens with capabilities.

 _C++_. Oh lord. Why are you writing a microkernel in C++? If there was anything they learned from L4 (Xen, Linux, ...) it is that C is sufficient. Why do you want to implement something small with something that is large? This one is a real head scratcher.

 _Provably secure_. They did this with the SEL4 microkernel so this is a doable thing. If they're going to hang their hat on security (capabilities, microkernel, ...) there's no excuse for not having done this already and delivered a provably secure microkernel out of the box.

<comment><USER17> >C++. Oh lord. Why are you writing a microkernel in C++? If there was anything they learned from L4 (Xen, Linux, ...) it is that C is sufficient. Why do you want to implement something small with something that is large? This one is a real head scratcher.

Because if there was anything proven from years and years of using C, it's that it is woefully insecure and should not be trusted to write a kernel with.

You can still fuck up with C++, sure, but std::shared_ptr offers more guarantees than *.

EDIT: HN stop eating my stars

<comment><USER16> Yes, we know that C is not secure. We also know that C++ is not secure and moreover it definitely isn't _C, now with security_. It's just more bigger C. So use your phrase, _you can still fuck up with C++_. You can just do it in more clever and insidious ways.

seL4, a third-generation microkernel is 8,700 lines of C code and 600 lines of assembler.

[http://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4....](http://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4.pdf)

So we also empirically know that you can formally verify a microkernel written in C. Now if the Fuchsia folks had gone ahead and formally verified their microkernel, this issue would be moot. But they haven't. So we are instead left with _std::shared_ptr offers more guarantees than_ __*. While this isn 't nothing, it isn't much either.

<comment><USER18> I wouldn't use SEL4 as an argument. It is completely unreasonable to build a production kernel the way they did - it took them _ages_ to get what they had. Google is probably looking to develop features/ move code a lot faster than is possible using their technique.

Good coding practices take no time to implement, you learn it once and you write that way. It is not bullet proof, neither are capabilities. Still, at least they're practical.

<comment><USER19> How about Muen separation kernel in SPARK Ada with automated prover eliminating many classes of undefined behavior? Or C with tools like Frama-C and Astree Analyzer (like SPARK for C)? C++ can't reach the safety of its competition due to more complexity and less tooling.

<comment><USER20> To be fair, if Frama-C is an option, as someone on the C++ side of the fence (C vs C++) I would advocate High Integrity C++ is also an option. :)

[http://www.ldra.com/en/software-quality-test- tools/group/by-...](http://www.ldra.com/en/software-quality-test- tools/group/by-coding-standard/high-integrity-c)

<comment><USER19> I thought about it. The reason I left it off is a lack of static analysis, automatic generation of tests, certified compilers, etc. There's tons of FOSS and commercial vendors for doing such things in C with quite a bit for Ada. Whereas, I could find only one or two products for C++ that seemed like it would be _really_ helpful as opposed to just kind of. So, I pivoted my recommendations to go with languages that have huge, tooling ecosystems in academic R&D and commercial. You can certainly use it but might get less value in long term.

Embedded, real-time Java could also be on the list since Java ecosystem has a verification tool for about everything. CompSci loves Java for some reason (probably mandated classes). Yet, verifiable C and SPARK are closer to the metal than embedded Java plus no Oracle risk. So, left off Java as well.

<comment><USER20> I guess so, I just know it from reading about it, so it might be that when using it won't be as suitable as I think it could be.

On the Java side you can probably check what Aonix used to do, they are now part of PTC.

[http://www.ptc.com/developer-tools/perc](http://www.ptc.com/developer- tools/perc)

Also there are the guys from MicroEJ.

[http://www.microej.com/products/device-software- development/...](http://www.microej.com/products/device-software- development/microej-os/)

There is no Oracle risk with Java, when companies play by the rules.

PTC, Aicas, IBM, MicroEJ, Excelcior JET, HP, Cisco, Ricoh, Azul, Red Hat and so many other companies are selling JDKs with their own set of features, without having had any issue with Sun or Oracle.

Only Google has an issue with Oracle, because they decided they were the cool kid better than anyone else whose rules don't apply to.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Are there enough clues to figure out if this is intended to eventually displace Android, ChromeOS, the Ubuntu distribution most googlers use on their company machines, or the Linux they run their data centers?

As far as I know, Google hasn't telegraphed the purpose of it. I can't tell if it's targeted at all, none, or some of the above.

<comment><USER22> Your guess is as good as mine, but there are some clues:

[https://techspecs.blog/blog/2017/2/14/googles-not-so- secret-...](https://techspecs.blog/blog/2017/2/14/googles-not-so-secret-new- os)

[https://techspecs.blog/blog/2017/2/15/proof](https://techspecs.blog/blog/2017/2/15/proof)

<comment><USER23> Thanks, but would sooner recommend my third article: [https://techspecs.blog/blog/2017/3/15/fuchsias- hypervisor](https://techspecs.blog/blog/2017/3/15/fuchsias-hypervisor).

<comment><USER21> The link in the bottom of your first article was very helpful, and seems to confirm ChromeOS and Android would be the likely targets.

[https://fuchsia.googlesource.com/magenta/+show/master/docs/m...](https://fuchsia.googlesource.com/magenta/+show/master/docs/mg_and_lk.md)

<comment><USER23> Thanks. Yeah, they really could not be more transparent about that. Most of the bring-up is on mobile + PC silicon as well.

There's no need to kill Chrome OS for the education, mind.

<comment><USER21> Looked at it again, and it could be an old comment about magenta, and maybe not applicable to fuchsia?

<comment><USER23> Well, the OS is most strictly the kernel, right? It's honestly all together. It's an SMP system that you can already run on normal ARM and x86 devices.

The team has stated that everything in the kernel is true, and that there's quite a lot there to infer from. What they can't say publicly is the how and why, e.g. how would they hypothetically implement backwards compatibility with Android apps?

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> I'd just like to interject for a moment. What you're referring to as Fuchsia, is in fact, GNU/Fuchsia, or as I've recently taken to calling it, GNU plus Fuchsia. Fuchsia is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Fuchsia", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project. There really is a Fuchsia, and these people are using it, but it is just a part of the system they use.

<comment><USER25> It's built with Clang and has a mostly BSD userspace.

</comment></comment><comment><USER26> People that question the existence of Fuchsia need only remember why Chrome was created. A lot of people thought Google was wasting their time by building a browser, including Eric Schmidt, and look how that turned out. Now, I'm not saying that Fuchsia will have the same success as Chrome, but it's clear that they think that having an OS that they can control the direction of is important to them.

<comment><USER27> Chrome was based on WebKit, and they bought Android (already based on Linux). Neither one was made from scratch.

Google certainly has the resources to do something like this. But neither of those projects (others mentioned Android) were started from scratch at Google.

<comment><USER28> They've build Webkit sandbox from scratch AFAIK. That's not exactly rebranding.

<comment><USER19> The security of Chrome was inspired by OP Web Browser and SFI schemes. Clever but actuslly weaker than predecessors to boost speed.

</comment></comment></comment></comment><comment><USER29> If I had to guess, this looks to be a strong candidate for the embedded OS market. There are still lots of folks running VxWorks, QNX, ThreadX, Mentor Graphics' Nucleus, Green Hills' Integrity.

In fact, it looks _a lot_ like the same general design as Integrity, a microkernel capability-based architecture with as much as possible in user space.

<comment><USER26> Its modern rendering pipeline would suggest it has uses for far more than the embedded OS market.

<comment><USER30> I'm not so sure. Perhaps "embedded" is the wrong term, but more and more devices have full touchscreens on them, and if you are selling a high end device like a refrigerator, having the UI be fluid and feel high end is important as well. Not to mention TVs, car UIs, security system pads, and more.

<comment><USER26> Its rendering pipeline uses Vulkan which requires a very capable GPU. I'm sure you could put an expensive SoC into a refrigerator or TV, but it's going to cost you.

<comment><USER31> Can't wait to play games on my fridge!

</comment></comment></comment></comment></comment><comment><USER32> The one thing that stood out to me is the name of former Be employee Travis Geiselbrecht. If you are unaware, he created NewOS, which was forked years ago and became the kernel for Haiku.

I didn't realize that he was working for Google.

</comment><comment><USER33> I don't understand what the value is in writing a new original microkernel from scratch in this day and age when sel4* is free and open source, performance tuned for 20ish years, is security hardened, and is provably correct for both security and features?

This doesn't seem like a wise path to take.

* See [http://sel4.systems/](http://sel4.systems/)

<comment><USER34> I know nothing about differences between fuchsia and sel4 but it would be rather strange if something as complicated as a OS kernel wouldn't have many parts where you have to make trade-offs. People compete fiercely in the field of todo applications, I don't see why there shouldn't be competition in microkernel space.

Things changed in hardware in last 20 years and maybe we've learned something about software as well.

Not to mention that sel4 is GPLv2, which is kind of problematic for a commercial company.

In the end, the micro-kernel is a very small part of the whole stack.

<comment><USER19> I think author meant L4 kernels were performance tuned for 20 years to be the fastest. Then, one using applying such lessons was mathematically verified for correctness down to assembly. It's proprietary and open-source depending on what your end product will be. They'd probably even add features to it for a Google-specific version that leveraged as many proven compinents as possible.

<comment><USER35> SeL4 is still working on multithreading. It is probably not good enough for a user interfacing OS yet.

<comment><USER19> That's true in its current state. Remember, though, that they're working on multithreading in a way that ties into their proof from high-level spec down to the code down to the assembly. Googles people are just putting together a kernel with review & testing. They could take seL4, modify it for concurrency, check it with concurrency-related tooling, and still get quite a bit of assurance from original work. Proof no longer applies but most things it applied to haven't changed. And model-checkers for concurrency are among easiest tools to use in formal verification w/ TLA+ getting adoption even by mainstream companies.

</comment></comment></comment></comment></comment><comment><USER36> That whole handle idea of the 'capability' system, but especially its implementation with 'handles', sounds exactly like Win32 to me. I haven't looked at the source, can anyone confirm or explain what exactly is different?

<comment> david-given Roughly put: in a capability based system, if you have a valid handle for a service, then you can use that service. But the only way you can get a valid handle is to ask your parent process for one --- handles are unforgeable. So your parent gets to check that you're legitimate.

...but your parent, in turn, has limited permissions, because the only way _it_ can get a handle is to ask _its_ parent. And when you ask your parent for a filesystem handle, your parent doesn't have to give you the handle it has. Your parent might give you a _limited_ filesystem handle which only allows writes to /tmp.

...and when you, in turn, start a subprocess --- say, an instance of sqlite for use as a database --- you have to give it handles for the things it wants to do on your behalf. But your filesystem handle only allows writes to /tmp. That means that your sqlite instance can only write to /tmp too.

There's more to it than that, because in real life you also want to forward capabilities to other running services as part of RPCs, but you tend to end up with a natural container system with multiple redundant layers of isolation, all running at minimum necessary privilege, and all hardware-mediated.

Another really interesting capability-based OS is Genode:

[https://genode.org/about/screenshots](https://genode.org/about/screenshots)

[https://genode.org/documentation/general- overview/index](https://genode.org/documentation/general-overview/index)

It'll allow you to run complete OS kernels as capability-restricted Genode processes, effectively allowing virtual machines as first-class citizens.

<comment><USER30> That's actually really beautifully simple.

Thanks for this explanation, it really helped the idea "click"

<comment><USER13> And for another beautiful convergence: nowadays most software development is done in languages that naturally express capability patterns, namely memory- safe languages. That is, if you have a reference to an object or value, you have the authority to invoke any of the methods on that object or call any functions that accept such a value. So object references are capabilities.

Most such languages only go too far by allowing "ambient authority", whereby _any_ component in your program has the ability to turn a reference to a value that carries little authority, into one that carries significantly more authority. For instance, consider the file open API: you're essentially turning a string, which exposes no unsafe or security-critical methods, into an object that can literally destroy your computer. And literally _any_ library or component you use can open files. It's madness!

To make a memory safe language capability secure, you simply remove all sources of ambient authority. This mainly consists of globals that permits transitive access to mutable state, like file system APIs, global static variables that can reference transitively mutable data, etc.

These insecure APIs are then replaced with equivalent object _instances_ which you can pass around, eg. you can only receive the authority to open a file if you're given an instance to the directory object which contains that file. The entry point of your program would then change to accept various capabilities instead of just string parameters.

<comment><USER37> And as an even deeper correspondence: Once your language is memory-safe and capability-secure, you don't even need a kernel, let alone a microkernel. Rather than use hardware address spaces to separate and modularize components (the primary idea behind microkernels), you just pass capabilities around to your components. One component can't crash the whole system, because all it can access is the APIs you pass in to it. If you want to add isolated processes to your OS, just implement actors in your language: They're equivalent.

Of course, you can always have a bug in your APIs that allows an attack or bug to propagate. But that was always the case even without capability-safety. Capabilities can't give you _everything_ for free. :)

<comment><USER19> JX Operating System does something like this within a JVM. It runs on a microkernel but I think the mediation is app/language level.

</comment></comment></comment></comment></comment></comment><comment><USER38> Lots of interest in Microkernels since everyone got tired of kernel vulnerabilities. So who won the Tanenbaum–Torvalds debate? It is too soon to say (Zhou Enlai said that of the French revolution - almost 200 years after the fact)

[https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate)

The article says that the focus is on 'PCs, tablets, and high-end phones'. Wouldn't a more secure OS be relevant to server environment? Is the performance cost of a microkernel considered to be too high for a server OS? Is it too difficult to do?

<comment><USER20> Given the amount of shipped embedded systems and the hybrid designs from OS X and Windows, I would say Tanenbaum won.

The majority of embedded OSes have a microkernel design.

Also Windows and OS X have a kind of hybrid design, even if not a proper mikrokernel.

On Windows case,there are now a sandboxed kernel and drivers.

[https://channel9.msdn.com/events/Ignite/2016/BRK4010](https://channel9.msdn.com/events/Ignite/2016/BRK4010)

[https://channel9.msdn.com/Blogs/windowsserver/Device- Guard-i...](https://channel9.msdn.com/Blogs/windowsserver/Device-Guard-in- Windows-Server-2016)

<comment><USER39> Even with new features like Device Guard, Windows is all but a microkernel; parts of the GUI high-level primitives (like fonts) are in WIN32K.SYS. Even OS X moved a lot of drivers to kernel space, it's not a pure microkernel design like the Hurd.

If anything, the closest thing to a microkernel that is in wide use is Xen, or Hyper-V.

<comment><USER20> Which is why I said hybrid, I didn't say it is a mikrokernel.

In any case it is better than Linux will ever be.

Regarding Xen and Hyper-V, there is a systems paper that states hypervisors are the revenge of mikrokernels.

<comment><USER39> I am not sure what's left of the original microkernel design in the NT kernel. You could say Linux is hybrid too because of FUSE and VFIO.

But yes, I was thinking exactly of that paper when I mentioned hypervisors. It only applies to type 1 hypervisors though: not KVM, Beehyve, or OpenBSD vmm. Even VMware ESX is more of a hybrid kernel.

<comment><USER20> Windows 10 thanks to UWP, Pico procresses taken from the Drawbrigde project and the MinWin rearchitecture is probably more closer to that model than the NT 4.0 descendants were.

Regarding hyperviors, actually I think only type 1 hypervisors make sense.

The type 2 were just a workound due to lack of hardware support.

</comment></comment></comment></comment></comment></comment><comment><USER40> The memory mapping model is really interesting, since it moves a lot of that out of the kernel and into user-space, but it seems like it has more disadvantages than advantages. What am I missing?

<comment><USER41> Big advantage is better security.

<comment><USER42> And it can be a lot faster. Jumping in and out of the kernel is slow, shared memory is relatively fast.

</comment></comment></comment><comment><USER4> I see great advantages to offering a POSIX compatibility layer. It can be sand-boxed to the app's context instead of making it a system wide dependency. Getting existing apps to run out of the box, and then convincing them to adapt a leaner, narrower set of system calls is probably more valuable than requiring from-the-scratch development.

</comment><comment><USER43> > The default Fuchsia filesystem, called minfs, was also built from scratch. > The device manager creates a root filesystem in-memory, providing a virtual > filesystem (VFS) layer that other filesystems are mounted under. However, > since the filesystems run as user-space servers, accessing them is done via > a protocol to those servers. Every instance of a mounted filesystem has a > server running behind the scenes, taking care of all data access to it. The > user-space C libraries make the protocol transparent to user programs, which > will just make calls to open, close, read, and write files.

Plan 9 is not dead, it ideas live on in other projects.

<comment><USER44> You are confusing things that derive naturally from a microkernel architecture with Plan 9.

<comment><USER43> I dont understand your point.

I may be mistaken,but my understanding is that userspace servers accessible through the use of the fopen/fread/fwrite, etc. system calls was an idea that originated in Plan 9.

Furthermore, some people who worked at Bell Labs at the time now work at Google.

<comment><USER19> I'm not sure Plan 9 was first with it. It was inspired by UNIX which was a watered-down version of MULTICS. That was a microkernel-based system with generalized I/O with open/read/write:

[http://multicians.org/rjf.html](http://multicians.org/rjf.html)

Now, the question is when was same concept applied to user-space servers? It was possibly Mach that was UNIX-like with all processes communicating through ports that were like standardized pipes.

[https://en.wikipedia.org/wiki/Mach_(kernel)](https://en.wikipedia.org/wiki/Mach_\(kernel\))

You got user-space components to open them, read them, write them, etc. That was 1985 whereas Plan 9 hit universities in 1992. Both models had security and performance issues that led reliability- and security-oriented OS's to go different routes on purpose. Plan 9 was a step up from UNIX but a step down from high-assurance (eg KeyKOS, NonStop) and high-flexibility systems (eg SPIN OS, LISP machines).

</comment></comment></comment></comment><comment><USER45> I know that I am excited that they will be providing soft realtime threads. I've felt this is a necessary addition for consumer media operating systems for a long time.

</comment><comment><USER12> > This is a new take on open-source development where it is out in the open, > yet secret.

Hasn't this always been the way Android operates? Developed in secret, source thrown over the wall every release?

<comment><USER46> I think this is more, that things are being developed without an explanation of its purpose. There's no "here are the new features in Android O" blog post

</comment></comment><comment><USER47> I can see the major point of making a microkernel is to allow kernel or other service (like driver) upgrade to be de-coupled; it would also allow much easier integration of non-open source driver and service, which could be a pain with Linux as it doesn't provide a clean way to do without rebasing (which could explain why Android upgrade is much lag behind for existing phone). But don't get me wrong, I totally support Linux philosophy.

</comment><comment><USER48> Fuchsia on RISC-V. That would be interesting.

</comment><comment><USER49> Is there an ISO?

<comment><USER50> It's relatively straightforward to build a bootable image:

[https://fuchsia.googlesource.com/docs/+/master/getting_start...](https://fuchsia.googlesource.com/docs/+/master/getting_started.md)

</comment></comment><comment><USER51> superb prose

</comment><comment><USER52> Fuchsia sounds awesome. Allowing user space processes to do more of their own work frees up the kernel from providing standardized interfaces to hardware.

This makes it significantly easier to build a closed platform with unbreakable barriers between processes, and this is a great thing in terms of security and fine grained access controls for each process. Individual process isolation is extremely important for most of todays use cases where only a single user is logged into each system at one time and most running code is trusted.

In practice this means you can prevent user space processes from accessing anything you don't want them to touch while still giving them substantial low level access. This will be a boon with device makers because it allows them to preventing a users apps from compromising the carrier experience. Companies like Google will also have less concern about users installing malware like ad blockers. The movie and music industry will also greatly appreciate an operating system finally designed for 21st century IP protection. This will even be embraced by hardware manufacturers since they no longer need to provide open source drivers for their hardware that could be ported to other platforms. Overall a win-win for everybody.

In the end we can trust that this will result in a better user experience with more secure apps and devices.

Did anyone hear the whispers of Xooglers a few years back talking about "big changes" coming to Android that were absolutely horrible for users and done to placate industry? Hmmmm... This Fuscia thing looks pretty suspicious.

<comment><USER53> This is a complete misunderstanding/misrepresentation of what a microkernel is. Even GNU is developing their own microkernel, the HURD.

<comment><USER52> I may be overly paranoid, but the majority of what Fuscia is trying to accomplish is extremely bad for open platforms.

The outcome of moving drivers to user space will be proliferation of binary blobs and black box drivers. If you think binary GPU drivers are bad now, imagine an "open source" OS where every single driver is a binary blob. It will become impossible to run Fuscia devices on any other operating system because you have no drivers, sealing off the Android platform permanently.

<comment><USER54> >If you think binary GPU drivers are bad now, imagine an "open source" OS where every single driver is a binary blob.

The current situation is they're tied to a version of the kernel, and typically abandoned by the vendors. With userspace drivers and driver APIs, the "android upgrade problem" would be solved.

It'd then be a matter of reversing these drivers, which should be far easier when they're running in userspace and completely bounded.

</comment></comment></comment></comment><comment> thunder-ltu I don't want or need any new OS or product from this company. Everything they touch, initially looks super exciting and positive, until they grab you by the balls once the competition is out.

<comment><USER55> Specific examples might help to evaluate this generic claim.

(I work for open-source projects at Google, and don't see your claim being universally or even mostly true)

<comment> thunder-ltu How many antitrust cases there are pointed at Google in EU alone? It's a one thing to work for open-source projects, another is to orchestrate the entire charrade that's about to be unleashed onto the users.

Everything at Google, from it's original product (search engine) to embedded devices, medical research, entire Alphabet portfolio is aimed at __total __dominance of every area in people 's lifes. It's an evil company in my eyes, it's been a long time since I retained at least some trust in this company and it's vision.

</comment></comment></comment><comment><USER56> I somewhere heard about a Google X OS? Is this it?

</comment><comment><USER57> Was anyone else bothered by the passive voice in this article? I found it really distracting.

</comment><comment><USER58> Google has repeatedly prommised, and failed to build a lightweight open OS. Every time they have produced one it was full of bizzare political constraints and closed source spyware. I would be shocked if this time was any different.

<comment><USER59> I don't recall this happening, are you referring to chromeos and android? Can you share some links if you're not?

</comment></comment><comment><USER60> While this is a cool project, I can't really see it making financial sense...

> Lets throw away the last 20 years development on the linux kernel by > thousands of people, and rewrite our own.

> How much will it cost?

> Ooh - I dunno - If you lend me 1000 engineers, we should be done in about 10 > years, cos we're really smart and don't need to implement legacy SCSI > support...

<comment><USER61> UNIX, as a viable OS model, isn't the last word in operating system design. It has too much design decisions and other baggage rooted in technology dating back to the 1970s. As Rob Pike, one of the people who worked on UNIX, said " _Not only is UNIX dead, it 's starting to smell really bad._"

On top of that, Linux essentially sucked all the air out of the UNIX development space by killing off all the commercial UNIXes. Carrying Linux forward rests largely on the shoulders of the kernel team and whatever contributions other businesses feel like making.

So where is the next major OS coming from? Google and Microsoft are the last two companies with the talent to build a future OS and enough resources and clout to push it enough to get traction. (In theory, it could also come from the community but people like Linus only come along once in a generation.)

<comment><USER62> > Linux essentially sucked all the air out of the UNIX development space by > killing off all the commercial UNIXes.

Only because they have done a really good job.

<comment><USER63> Eh. The biggest thing Linux had going for it in terms of winning market share was running on commodity x86 parts in a time period when the commercial Unices weren't touching it, and x86 made really strong gains in beating everybody else at performance per dollar.

<comment><USER64> > The biggest thing Linux had going for it in terms of winning market share > was running on commodity x86 parts in a time period when the commercial > Unices weren't touching it

From the 1980s to 1993 there were:

        v7 ports: Microsoft Xenix (later became SCO), Venix, Coherent
        System III ports: PC/IX (later 386/ix)
        SVR3 ports: official Intel, ESIX from Everex
        SVR4 ports: Dell UNIX, Novell UnixWare, Microport

<comment><USER63> Okay? Red Hat Enterprise Linux wasn't released until 2000, so I don't know what Microsoft's late-80s UNIX distribution has to do with it. Google was running Linux from the early days, and they launched in 1998, which is nearly a decade after Xenix stopped being updated.

EDIT: Yes, Linux has its origins sooner, and if you want to know why Linux beat the BSDs to mindshare, what was going on in 1993 is very important. But Linux wasn't competing for mindshare with Xenix, it was stuff like Solaris (which did have an x86 port, but was mostly running on SPARC), AIX (which was mostly IBM big-iron and POWER), HP-UX (which was PA-RISC and IA-64), etc.

<comment><USER64> If you want to talk about post-1993, saying that Linux won because there weren't any commercial x86 Unices makes even less sense. Xenix did not stop being updated, it became SCO UNIX. SCO bought and continued to sell UnixWare from Novell in 1995. x86 Solaris came out in 1993, but Sun actually had an x86 Unix since 1991 when they bought ISC.</comment></comment></comment></comment></comment></comment></comment>


AMD and Intel Had a Baby and It's a Beast - <AUTHOR> https://seekingalpha.com/article/4164382-amd-intel <comment><USER2> On mobile this site attempts to force installation of an app to read the article.

Workaround: [https://archive.is/ZzIiK](https://archive.is/ZzIiK)

<comment><USER3> Your link i̶s̶ was giving me a 503 error, so here is a transcription of the article for mobile users:

AMD And Intel Had A Baby! And It's A Beast!

• In early February of 2018 we published an article about the cooperation between AMD and Intel, or as we dubbed it, AMD's hidden strategy against Nvidia.

• Now we look at the first fruit of that strategy, the Intel Hades Canyon NUC, a powerful small form factor computer.

• The Hades Canyon NUC is capable of running AAA title games at 1080p without a problem, proving that AMD's strategy should work flawlessly.

In early February of 2018 we published an article about the cooperation between AMD (AMD) and Intel (INTC), or as we dubbed it, AMD's hidden strategy against Nvidia (NVDA). Please read the original article for more background, but we will summarize some of the key points here.

AMD is now cooperating with Intel. Yes, indeed, hell just may be frozen over at the moment. AMD is selling Intel its Vega GPUs in silicon form, no IP transfer. Intel then packages these Vega GPUs on the same substrate with one of its CPUs to make what AMD calls an Accelerated Processing Unit (APU).

(Image of Intel CPU and Vega GPU attached to a single CPU socket board)

The GPU communicates with the CPU via an 8x PCI-E bridge and shares power circuitry to create better efficiency.

Ok, so that sounds good for Intel, but aside from shifting more GPU cores, which AMD already has no problems doing, what is the benefit for AMD? Ah, but that's the "hidden strategy!" You see, one of the biggest hurdles AMD has to deal with at the moment is software support. Nvidia, AMD's GPU rival, has a stranglehold on the higher end gaming market at the moment. As a result, most of the games coming out on the market are optimized for Nvidia's GTX GPUs first, and are only later tweaked to perform well on AMD's hardware.</comment></comment>


Why is the violin so hard to play? - <AUTHOR> http://plus.maths.org/issue31/features/woodhouse/index.html

<comment><USER2> Interesting side-topic: how many hackers out there are also musicians, and what do you play? I started playing violin when I was 2, but haven't played so much since leaving college. Maybe we could get a quartet together or something... you know, "I'm starting a hacker quartet, BUT I'm still going to work on my startup" :)

<comment><USER3> Violin was my first instrument, but I've mostly played guitar for the past ten years or so. I guess I was a musician long before I was a hacker, and I see a lot of similarities between the two - the variety of things you can do, the amount of time it takes to become decent at either, etc.

Surprisingly enough I've never tried to bring the two together. Signal modelling/processing software...talk about 'hard problems'!

<comment><AUTHOR> I took a similar path - violin for 9 years, then switched to guitar when I was about 16 (to be cool, of course). I didn't completely drop the violin, but guitar was my main instrument for the later part of high school. But then I picked the violin up again for All States my senior year, and kept doing it for college. Surprisingly it's violin that stuck - I still play a couple times a week, while I haven't touched my guitar in close to a year.

I've also dabbled in a bunch of other instruments - 3 years of clarinet in middle school, enough viola to play and (barely) read music, picked up a fife and tin whistle in Williamsburg, reasonably fluent on bass guitar, and I've been trying to teach myself piano over the past couple years, with only slight success.

</comment></comment></comment><comment><USER4> This is the best article to come out of the switch to hacker news yet. _exactly_ what I'd read all day long, time permitting.

<comment><USER5> You might find this book interesting:

[http://www.amazon.com/Equal-Temperament-Ruined-Harmony- Shoul...](http://www.amazon.com/Equal-Temperament-Ruined-Harmony- Should/dp/0393062279)

Conversationally written and accurate (so far as I was able to tell, I only had time to read a few chapters)

</comment></comment><comment><USER6> I think what attracted me to the fiddle was a) the belief that the goal was to expend as little effort as possible, and b) it had very few parts.

I think these are same things I look for in programming languages. Maximum expressibility with a minimum of interference.

The violin is the Lisp of musical instruments.

(Or, Lisp is the violin of programming languages.)

</comment><comment><USER7> Not having frets doesn't help, either.

</comment><comment><USER8> The hardest part of learning to play (and to master) the violin is definitely learning how to use the bow. Actually learning how to play in tune is hard as well. It's just hard.

<comment><USER9> Yeah, I was surprised that the article didn't even mention intonation. That deserves some lip service at least.

</comment></comment><comment><USER10> I play several instruments, but it's the violin playing that goes rusty quickest. Past a certain stage, you can get out of practice with just one or two weeks of neglect.

</comment><comment><USER11> the article deals only with the mechanics but surprisingly, omits the really hard part - getting emotion to be depicted in the violin tone. that's why I gave up the violin after 3 years.</comment>


Color Changing Hair - <AUTHOR> https://www.youtube.com/watch?v=-uG-YAW9io4

<comment><AUTHOR> More on it, [http://mashable.com/2015/05/29/color-changing- hair/](http://mashable.com/2015/05/29/color-changing-hair/)</comment>


VR Resources - <AUTHOR> http://facebook.design/vr <comment><USER2> "Subject to your compliance with these terms, you may use the Facebook Design Resources solely for creating mock-ups, including displaying such mock-ups in digital or print format. The Facebook Design Resources may not be embedded in any software programs or other products without express written permission."

Cool stuff, but not super practical?

<comment><USER3> It's practical for designers, which is what these resources were designed for.

<comment><USER2> That makes sense.

</comment></comment></comment><comment><USER4> The Sketch VR template and its accompanying Unity project, which projects the Sketch document onto the inside of a 14-meter sphere, is a VR prototyping workflow that never occurred to me.

I wonder if Serif, makers of Affinity Designer and Affinity Photo, would want to expand in this direction: Photo (Serif's Photoshop usurper) just added a very interesting real-time 360° view ([https://affinity.serif.com/en- us/photo/new-features/](https://affinity.serif.com/en-us/photo/new- features/)). HMD support would make this a viable, standalone VR sphere- prototyping tool.

</comment><comment><USER5> How practical is it to get into programming for VR for cost sensitive developers? I feel like this space will not blow up until the tools and resources become fairly accessible for the common developer.

<comment><USER6> I also recommend the Vive as the most viable.

If you prefer sit-down VR and don't see the potential in room-scale VR, then I would recommend the Fove.

It has eye-tracking which allows for focusing rendering resources around your gaze as well as some cool interaction and less stress on your neck.

John Carmack was sniped by Oculus while back to figure out things like inside- out roomscale, specifically with the Gear VR, so you might be keen to keep up with those developments.

Gear VR is fairly affordable if you have a compatible phone and will hopefully stay that way once they implement Carmack's reverse tracking.

<comment><USER7> Avoid GearVR and go with Daydream if you can manage it: GearVR used Android to bootstrap itself but locks things down similarly to Amazon Fire phones. Just go with Daydream, it is "real" Android and avoids adding another locked down system to our lives--you don't have to get special keys from Facebook to send out your app like you do with GearVR, and third party stores are allowed and practical.

<comment><USER6> Thanks for sharing. I didn't realize that Facebook required developer keys for the Gear VR.

I don't support Oculus because of the Facebook buyout, but I am a Carmack fanboy and I hope that he is pushing for GearVR / Oculus to make his methods for inside-out tracking publicly available.

Do you have Daydream HMD and if so, what is your experience with it?

</comment></comment></comment></comment><comment><USER8> The thing that gets me most excited about VR is how ready everyone will be for AR.

</comment><comment><USER9> I wonder what the underlying assumption is here from Facebook. Is it the notion that

1) VR headsets will get comfortable

2) VR users will want to connect with friends

3) VR will get killer applications and FB wants to be a platform like it did with Games/Spam?

4) Returns will be realized before FB becomes insolvent?

All in all, facebook gets a low score for me because people are starting to realize the toxic effects of being "connected". More people I talk to, the more I see "off grid" peeps like me. Great platform for narcissist to maximize their attention as trolls are to Youtube comments and Reddit. Even people who are on FB are not the same as 8 years ago, sporadically checking. The upcoming demographic seems to be more geared towards Snapchat-esque mediums.

Secondly, I'm concerned by the volatile landscape of "social" apps. FB forked out so much money for it's past aquisitions such as Whatsapp, Instagram...okay I get it buy out the competition to avoid becoming MySpace... but Oculus Rift purchase was the most troubling one of all because it showed that FB is becoming increasingly anxious about it's future relevance by betting on extremely early poorly adopted tech with questionable prospects (imo VR will fail for the same reasons it did in 90s, people don't want to spend long time or spend doing things they can do on a normal computer). This anxiety is further fueled by Zuckerberg's race to China while failing to see that WeChat, Baidu, Snapchat, Uber all have one thing in common: Poor adoption by target demographic when strong incumbents dominate the market.

If I was a FB shareholder, I would be asking, how the heck are all these experiments which cost billions of dollars ever going to generate return before the low interest rate capital disappears with a strengthening dollar and looming protectionism? This VR resource page communicates and confirms my suspicions.

FB's VR resources is interesting of course as a fun dev toy, but seeing how Google spend so much money chasing after "Xperimental out there" ideas and still hasn't seen ROI, it's worrying to see a company that isn't printing money spend investors cash so carelessly.

<comment><USER10> VR and AR are the future of HCI. Facebook wants their stock to continue going up and Mark wants to continue being relevant.

<comment><USER11> VR and AR _might_ by the future of HCI. Facebook is making a bet.

</comment></comment></comment><comment><USER12> VR Resources? This?

I have an archive of several gig of information, papers, code, software, images - you name it - that stretches back detailing VR to at lease the Ivan Sutherland "Sword of Damocles" era (and actually, before that even - plenty of stuff came before his demos that hinted at things - Hugo Gernsback had more than a few covers of his pulp-scifi mags that covered VR and AR ideas in the 1920s and 30s, for instance).

Do most people think that VR is a totally new thing?

<comment><AUTHOR> I think I originally submitted it as "Facebook Design: VR Resources", but the mods did the HN thing where the title changes to directly match the original. This is in no way meant to be a general VR knowledge dump, it's specifically a set of resources that Facebook has produced targeted at designers that traditionally work on web and mobile design and are new to VR UI.

The most interesting thing on the site is the publicly available version of the VR hand models used in the Oculus home UI and all of their games and demos, which were previously only available if you had a relationship with Oculus developer relations.

<comment><USER13> I hate those title changes. Some page titles are completely useless when taken out of context. I really don't understand the zealous application of that guideline on HN.

</comment></comment></comment><comment><USER14> this is all cool but vr design is more game design than app design.

why take a bunch of app product designers and make them do vr apps?

doesn't make sense. get game designers to do it.

<comment><USER15> Completely disagree. Half of VR experiences aren't games: Tilt Brush (3D Photoshop/painting), Medium (3D Z-Brush/sculpting), Google Earth VR (3D map), and so many more which aren't concerned with "game design" or "playability". They're all used via a combination of physical and digital interactions, requiring a mix of UI/UX and industrial design insights.</comment></comment>


Twitter has suspended 125,000 accounts promoting terrorist acts - <AUTHOR> http://www.marketwatch.com/story/twitter-has-suspended-more-than-125000-accounts-promoting-terrorist-acts-since-mid-2015-2016-02-05 <comment><USER2> would be interesting to see what was the content actually promoted and what they consider a terrorist act. I wouldn't be surprised if one is critical about US military actions this would also fall under "promoting". Hard to understand what this means. I think we need our open decentralized web back where information can not be made disappear by one who doesn't like the content. We criticize the same censorship if some backward country like Turkey or Egypt is doing it. Yet in the name of the war on terror the same people are calling for torches & pitchforks.</comment>


Ask HN: Naming my startup, should it end with "app"? - <AUTHOR>

I'm working on a new startup/project for GAAP compliant accounting software, competing directly with QuickBooks and Peachtree and am at a creative loss for naming it. I want to come up with a name as clever as EverNote. Obviously, domain availability is key since we're bootstrapped. There are varying schools of thought when it comes to having a domain that is the exact name of the company.
Despite what 37signals says, I think basecamphq.com is a horrible name. I have had dozens of people to which I referred Basecamp, give up because they couldn't figure out the domain. I don't blindly trust everything 37Signals says as gospel. Notice how they never admit to any mistakes they've made? Anywanys... </rant>
Lighthouseapp.com is another example of a postfixed name, but my market isn't tech savvy developers.
One name I love is RunRate. The domain isn't available. So what about RunRateapp.com?
Anyone have any killer ideas? <comment><USER2> I think there are enough SaaS product around to warrant a .app domain, then runrate.app/ would be my suggestion. (I live in the theoretical)

</comment><comment><USER3> __hq, get___, ___now

All these are nice "sufix/prefix naming conventions." For my startup, I use HQ(ChalkboardHQ.com).

Here are some possible names for you:

\- RunRateHQ.com \- GetRunrate.com(I really like the sound of this one) \- Runratenow.com(This one sounds like decisive and makes me sorta want to hop into it and try it)

Good luck with the naming, if you'd like, we can chat(hajrice@gmail - gtalk), I have a lot of ideas and could maybe help you more.

<comment><AUTHOR> I like Getrunrate. It actually has a nice ring. Hmm... My Gchat is email@example.com

</comment></comment><comment><USER4> If your product is killer I don't think it matters what your domain name is. People are going to get the word out.

Look at "blekko" for crying out loud.

<comment><USER5> Blekko is still very far from proving that its horrible name wasn't a huge mistake.

<comment><AUTHOR> Well it is short, unique and _somewhat_ phonetical. I'd give it a B.

<comment><USER6> We hired a naming company, and they couldn't come up with a better name -- most of their suggestions were too boring.

<http://www.skrenta.com/2008/01/about_the_name_blekko.html>

If we succeed, the name will be considered great. If we fail, people will blame the name. Does the name really affect anything? I bet good results are more important.

<comment><AUTHOR> Mind if I ask how much you paid the naming company? Unless you have money to burn, I can't imagine paying a company to name your startup.

<comment><USER4> My employer paid for a branding agency and wound up throwing away most of their names and settling on a name we came up with ourselves. They did give us one good name that I wound up using for a logging tool two years later, so it wasn't a total waste.

I'm of the opinion that if you don't have creative enough people on your team to come up with a good name you probably have bigger problems than the lack of a creative name.

</comment></comment></comment></comment></comment></comment><comment><USER5> App is crap. _Maybe_ it's okay if you're a mobile-only product.

Since you're going to be dealing with people's money you want something that imparts a sense of trust/stability/credibility. You should probably spend up to a couple grand (if you can) on a great domain.

Your name (AND DESIGN!) is a huge factor for this kind of company. Follow Mint's example.

<comment><AUTHOR> I agree completely. I don't think we necessarily need to spend a couple grand on a domain to deliver on those senses, but you're dead on with design. Thank god I'm a UI rock star. Maybe just Guitar Hero level rock star...

</comment></comment><comment><USER7> Be creative with TLDs maybe if .com and .net or your countries TLD is no longer available (.de, co.uk etc)

I feel like I've seen .io more often recently. It fit my app perfectly, well, because it takes stuff in and gives stuff out (I/O, will also make for a cool logo).

<comment><AUTHOR> I like this, but if your market (namely small businesses) is not very technology literate, explaining the non .com name is tough.

I've had enough clients that have called me asking why the example.io.com doesn't work. They were surprised when I explained that not all websites end with .com. Go figure...

</comment></comment><comment><USER8> I'm also in a similar situation. The name I'd like for my webapp is taken and i'm considering _hq.com or_ app.com. Or would it be better to use a .net or .biz?

<comment><AUTHOR> That's a good question. What's better, a .net, etc. domain, or a .com with a post-fix.

My personal opinion is to pick a more unique name. But, I'd say postfix is better. The domain name without the domain code is more brand-able than the full domain e.g. BaseCamphq is recognizably different, but doing basecamp.net wouldn't be as unique.

</comment></comment><comment><USER9> Always get a .com if you can.

How about ledgerleader.com - thats available.

I might be willing to sell bitsprout.com if you like it - but I may also use it.

dollardoc.com littleledger.com mintbit.com dinerodocket.com

all available....

If you'd like some other ideas - i'd need to know more about your app.

<comment><AUTHOR> Funny story: I posted a crowdsourced project to name this. All these ideas are better than the dozens of entries I've received so far. I posted a comment describing why I like EverNote as a name, and its mechanical relation to their business. Entries started flowing in with the words "ever" and "note" in them. Face palm.

So we're developing an online accounting system for entrepreneurs, startups and eventually lifestyle small businesses. It will combine the beautiful interface of Mint.com with the rich features and GAAP compliance of QuickBooks. We'll be sporting automatic bank pulls and reconciliation. The goal is to have an accounting application that is always updated and reconciled, so it actually can be used as a tool to make financial decisions with, and not used as an after though.

I like the alliteration examples here. I think mintbit is too close to Mint and dinerodocket is too close to inDinero (both substitutes, but not direct competitors). I'd LOVE more ideas :) One I'm leaning towards is ledgered.com. My partner didn't like it, but I just want to make sure I'm not crazy.

<comment><USER9> since its an auto reconciling app - how about ledgerbot.com -- it is available and seems to carry many of the aspects of what you are looking for.

Can make a cute logo from that idea etc...

Yeah, I like alliteration as well - you have to have a name that captures your product, is a .com, is easy to spell and rolls off the tongue. Then, it will never be forgotten.

One of my first thoughts was "account.ly" would work - its registered to a guy in carlsbad... but looks like he is trying to build something.</comment></comment></comment>


Ask Hackers: Are you planning to do your startup in Arc? - <AUTHOR>

What are your Arc related plans?<p>Please share your thoughts. <comment><USER2> to be honest i'm tired of all this language talk. The fanboism surrounding lisp, haskell, arc, scheme, erlang, and other less popular languages is getting to be a little too much

Languages don't matter!

When I first started programming, I was so impressed by superhackers who knew like 10 languages or were experts in obscure ones like Forth and whatnot. Then as I learned more languages, I realized that languages are just interfaces into the computer system. Thats it.

Arc won't be able to do anything that binary code can't do.

This is nothing against pg. If you want to create a language because that interests you. Great! I'm just tired of all the elitist fanboys mentally masturbating over how great their language is. maybe i just read programming.reddit too much tho ;)

<comment><USER3> Aw, man, you fed the troll with an _even larger_ troll.

This is going to be messy.

Maybe I can defuse the situation with the Premature Godwin Maneuver. Look! Over there! It's Hitler!

<comment><USER4> We just went from 19 to 20. (Or worse.)

</comment></comment></comment><comment><USER5> If you want to write a ton of your own support libraries, feel free to join the fray. While you're writing a library to upload files to S3 (or whatever), others are going to be implementing actual website features in Rails. Do you see where I'm going with this?

<comment><USER6> I think you make a good point but also consider,

MZ Scheme links trivially to C libraries. I would think that anyone who uses Arc would use this facility heavily. Now whether there exists a C library to do exactly what you want is a different question. And I know this might be heretical here, but ROR is hardly the great time saver the fanboys make it out to be when you count in issues like deployment and doing non standard things with it. (Don't get me wrong, it is a good framework, but it is hardly a magic wand and neither is it very unique - Wicket + scala comes very close to ROR in productivity for example)

PS: How long do you think it would take before people hack up a virtual machine or C code emitter? I, for one would do exactly this if I planned to use it in my startup. It isn't _that_ hard (Ruby's recursive descent sloooww interpreter still powers all those RoR sites, minus the vanishingly few ones in JRuby.)

<comment><USER7> I've dealt with a couple systems that link Lisp 'trivially' to C. When they say they link trivially, what they mean is that they let you call the function in the C library just like you'd call it from C. This is frequently extremely not how you want to do it in Lisp, and so you're forced to either a) write a Lispification layer, in which you take all the C functions and turn them into a library that acts like you want a Lisp library to act (the usual approach), or b) just write it like it's in C, which makes you very angry all day long, and also loses some of the benefit of writing in Lisp. Both approaches slow you down quite a lot. Especially if you decide not to be an asshole and release your lispification layer as open-source (which you should)-- because then people will all be pounding down your door for fixes and extensions and maintenance for new versions of the C library, which is not what you want to do. You didn't even want to write the layer to begin with, presumably.

So no, 'trivial' C linking not actually a silver bullet making everything hunky-dorey with respect to lack of libraries. Python has a significant advantage in that it's popular enough for many people to have already gone through the Pythonification process for most important libraries, and have also open-sourced their Pythonification layers.

</comment></comment></comment><comment><USER8> Not only do I plan to do my startup in Arc, I've already decided to use holographic storage to do my backups (it's big, you know).

</comment><comment><USER9> Doing a startup in something that's not even public yet?

<comment><USER10> lol... is it yc application season yet?

</comment></comment><comment><USER11> That's not really something I could answer at this point. I would never put my faith in a language that I haven't hacked around in.

<comment><USER12> Seems like you're a good candidate for a catch-22...

<comment><USER13> Not really - hacking around with Arc doesn't require faith in it (since the commitment level is well below the level where you would use it to implement your Next Great Idea). And of course hacking around in it is how he would become confident/impressed enough to use it for bigger things.

</comment></comment></comment><comment><USER14> @kirubakaran - "What are your Arc related plans?"

I plan to build the arc, set sail and bring 2 of every animal with me.

;)

</comment><comment><USER15> Is any startup ever "done" in just one language? Everwhere I've been there are a half a dozen.

Why not just wait to see what Arc ends up doing really well out of the box and then considering it for that and leave the things it doesn't handle to something else?

</comment><comment><USER16> I've been anxiously awaiting to give Arc a try for five or six years now. I don't necessarily have a particular project in mind for it yet, but from what I've seen, I expect to like it, and will start using it for SOMETHING as soon as possible.

<comment><USER17> Ah, I've got this one figured out. I'm going to use it to implement another dialect of CL... in which I will implement a dialect of Scheme... in which I will reimplement Arc. I'd like to see how many iterations of this one could go through before it becomes completely unusable even for simple arithmetic.

Assuming each one interprets the next.

</comment></comment><comment><USER18> No, but I may try Clojure. Because it runs on the JVM, there are lots of libraries, and I can always fall back to Java/JRuby if something doesn't work.

Arc and Clojure together may make for a great Lisp year.

</comment><comment><USER19> Writing code is only half of "doing a startup".

<comment><USER20> Depends on the startup.

Writing code is between 1% and 99% of a startup.

</comment></comment><comment><USER21> I'm doing mine in Arc#.NET.</comment>


Moving to Silicon Valley: What do I need to know? - <AUTHOR>

I'm considering moving to Silicon Valley from London.
I'm an American so while I won't have immigration issues I have a 9 week old son with a partner who is Polish.  I know I can get my son American citizenship, however I'm guessing getting my partner a visa will be a challenge.  We may even have to marry before we go (but I was planning on doing this anyway, I just haven't popped the question).
1) How harsh is it living in Silicon Valley?  Is it super expensive?  How much savings would I need to burn through before landing on my feet?
2) Is it really start-up heaven?  I get this sense that it is THE place to be in the world for tech start ups.
3) What is the good, the bad and the ugly?
4) What are my blind spots here?  What will I need to know or consider before I make the leap?
Thank you for your answers. <comment><USER2> 1\. It's extremely expensive, even out on the Peninsula or South Bay. Apartment prices have doubled and tripled in the last 5-10 years. San Francisco is more expensive than Manhattan. It'll be even more expensive for you, because your family situation will probably rule out most roommate situations and may determine which areas you can live in --- if that puts you outside the city, your commute budget is going to go way up.

2\. It's definitely _a_ start-up heaven. The start-up community in SFBA is unlike any elsewhere in the world. It is probably safe to call it _the_ place to be to get a job at a startup, and if not _the_ place to be to get one funded, it's at least in the top 2. That does not necessarily make it _the_ place to start a startup. For me, it's one of the worst places to do one.

3\. Good: Lots of access to other people doing tech startups. A tremendous tech job market for employees. Decent food, approaching the quality of the best cities in the country. Bad: Truly awful public transportation. Vast distances between SF and Mountain View/South Bay, connected by wall-to-wall traffic. Neither the Peninsula nor South Bay are casually navigable without a car (you can get almost anywhere without one, but you'll need to plan well in advance). Pretty much everything south of SF closes at 9:30, even on weekends. San Francisco is surprisingly small. Very little industrial/commercial diversity.

4\. Expect visa drama.

</comment><comment><USER3> 1: Not harsh. I hitch hiked here with no money and lived on Ocean Beach in SF for the first month I was here. I found a job, yes found, no nepotism or anything involved. I knew no one here.

2: There are a lot of startups here if that is what you define as startup heaven. Keep in mind that if you are starting a company you need to execute. If you are not executing and evolving your vision, no one will be interested in your shit unless they just want a paycheck and paycheck people are unreliable as hell. I have started and sold two companies here and this is what I have seen several times.

3: Good, bad, ugly... State income tax? You can make it as ugly or as awesome as you want.

4: Apartments in San Francisco are pricey. Buy vegetables in chinatown or sunset/parkside area. Chinatown is probably more convenient. Beer is good and cheap at the toronado room from 4 - 6 pm (I think)

If you are actually in Silicon Valley then I recommend ISO Beers, Bierhaus, Original Gravity and Whole Foods in Cupertino for good beer.

Beer is important.

Other than that I would say that you alone define your destiny. Fuck the tips. Just move and make shit happen. Nothing will fuck up your plans as nicely as life happening while you are planning some shit.

That is my platitude injection for the month.

</comment><comment><USER4> _a partner who is Polish... however I 'm guessing getting my partner a visa will be a challenge._

As a US citizen, you can bring your partner on K1 fiancé visa and get married within 90 days in US. K1 is quicker than marrying outside US and bringing your partner on Immigrant Visa or K3 spouse visa.

Start the K1 process now as it can take few months for the process to complete and permission to bring your partner.

[http://www.immihelp.com/visas/kvisa/compare-fiance- visa-k3-v...](http://www.immihelp.com/visas/kvisa/compare-fiance-visa-k3-visa- immigrant-visa.html)

</comment><comment><USER5> 2: the bay area is a large area. there are plenty of startups around, but except for some meetups and events you won't see much of it. don't expect a big warm fuzzy community close together in one area or smth.</comment>


Crowdsourced research: Many hands make tight work - <AUTHOR> http://www.nature.com/news/crowdsourced-research-many-hands-make-tight-work-1.18508?WT.mc_id=TWT_NatureNews <comment><AUTHOR> People looking at the educational effects of deworming children reach different conclusions because some of them use a medical model and some of them use an economics model.

[http://www.cochrane.org/news/educational-benefits- deworming-...](http://www.cochrane.org/news/educational-benefits-deworming- children-questioned-re-analysis-flagship-study)

[http://www.cochrane.org/CD000371/INFECTN_deworming-school- ch...](http://www.cochrane.org/CD000371/INFECTN_deworming-school-children- developing-countries)

Talked about in this More or Less episode: [http://www.bbc.co.uk/programmes/b0659q1f](http://www.bbc.co.uk/programmes/b0659q1f)

[http://www.theguardian.com/society/2015/jul/23/research- glob...](http://www.theguardian.com/society/2015/jul/23/research-global- deworming-programmes)</comment>


Ask HN: Someone in the bay area experienced in retail/eccommerce for advice - <AUTHOR> I am looking for someone who can give me advice about my idea. I am an engineer in the bay area, however my idea is in the intersection of ecommerce and traditional brick and mortar retail. I know next to nothing about retail and ecommerce, and so I don't know if my idea has any wings.
Would be extremely grateful if anyone could either make contact with me, or point me to someone who could help me out.
Thank you in advance HN. <comment><USER2> You should put contact info in your HN profile. Feel free to contact me that way.</comment>


Latent Semantic Analysis . . . in Ruby! (apologies to nickb) - <AUTHOR> http://classifier.rubyforge.org/

<comment><USER2> nickb ref: <http://news.ycombinator.com/item?id=155921>

</comment><comment><USER3> "apologies to nickb"

You mean PG, of course. NickB's just his sock puppet.

;-)</comment>


Google to demote pirated content - <AUTHOR> http://www.theage.com.au/technology/technology-news/google-to-demote-pirated-content-20120811-24176.html

<comment><USER2> Great, now I'll expect entire search results to disappear completely when a company tells Google that they own something.</comment>


Show HN: Where developers stay informed of API changes and discussion - <AUTHOR> https://hitchhq.com <comment><USER2> Hitch looks like a slick iteration on the API Changelog. Any plans to support the ability to search for APIs?

Also curious how Hitch would look if it could more easily detect changes via API providers providing a more formal specification (i.e. versioned Open API Specifications, Blueprint, RAML etc.. that could be diff'd). Guessing it is "challenging" today to either rely on API owners to make updates or to deal with more complicated web scraping.

</comment><comment><USER3> I guess I'm confused. The title of your post makes it seem as though you are a forum for APIs, but the site makes it seem much more like a marketplace. Am I reading it wrong?

<comment><USER2> My take is that Hitch is there to help developers stay informed (via push vs pull) about changes to APIs they are interested in and then to provide a forum to discuss those changes. I think the "marketplace" piece (i.e. Browse APIs) is really just to facilitate the ability to find the API you want to "Follow" for changes.</comment></comment>


No more dieting and other things we do differently after reporting on healthcare - <AUTHOR> http://www.vox.com/2015/5/20/8621527/health-tips-reporter <comment><USER2> I don't know about the author, but I buy my insurance not for my yearly cholesterol checks, but in case I need to hop on a plane and get treatment at a major medical center.

Narrow networks are unequivocally bad for people needing specialist care, which happens to be the main reason for health _insurance_.

<comment><USER3> _Nobody_ buys their insurance for yearly cholesterol checks.

They _think_ they do, and a lot of the ecosystem (providers, employers, politicians) reinforce that idea, but it's not something that actually exists.

That's because regular, routine costs (like new tires for your car) are NOT underwriteable. You can't insure for them, nor can you buy insurance for them.

If your insurance company is providing new tires every year or giving you wellness checkups every year, you're paying cash money for that _somewhere_. Even though they say it's an insurance benefit. It's not. Because math.

It's very difficult to have any kind of discussion about this when even this most basic of accounting identities is misunderstood.

<comment><USER4> To be fair, annual checkups (of many varieties), are not covered solely because people can't math.

If an annual checkup reduces the risk of a high-value payout then it makes very much financial sense for the insurance company to pay for the annual checkup for you, as an incentive for you to get one.

In fact, if the average insuree is very unlikely to pay directly for an annual checkup and the annual checkup helps to reduce the likelihood of high-dollar- value insurance claims, then it is reasonable for a "free" annual checkup plan to be cheaper than one that does not offer such "free" benefits.

Note: I am not disagreeing with your statements that the insuree is definitely paying for regular costs, nor that people don't math well. I am just raising some of the nuance around what behavior makes sense for an insurance company given irrational insurees.

<comment><USER5> Actually, if the insuree is rational, it _especially_ makes sense for the insurance company to pay for the annual checkup. If the insurance company only covers me when I get really sick, I lose money by going for the annual checkup -- I'm "better off" waiting to get really sick, and then having them cover all of my expenses.

<comment><USER6> You've defined rational as valuing money over health.

(the jargon rational economic actor maximizes value, not dollars)

<comment><USER4> Just an addition: rationality in economics assumes a logical[0] ordering of preferences and behavior which maximizes value within this ordering.

[0] Think transitivity: I prefer A to B and I prefer B to C; I must not prefer C to A. There's more nuance, but this is enough for the intuition. Without this ordering, maximizing value makes no sense.

</comment></comment></comment></comment></comment></comment><comment><USER7> I'm surprised there's so much hating on this article. I guess it's not the most original thing ever, but I think most of the points (with the possible exception of #8) are pretty well known and accepted. Fad diets are mostly crazy, overuse of antibiotics is rampant and harmful, overscreening can be a problem...

<comment><USER8> Maybe intent was good, but some advices are harmful. For example, 1 and 7. While in general it's not lie, but they can lead to thoughts "eat everything you want, just try to eat more "healthy" things, and "don't go to screenings at all".

<comment><USER7> If you tell someone to be careful not to fall off the right side of a bridge, and they then run away and fall off the left side, does that mean your advice was harmful?

Just because someone might overreact doesn't mean you shouldn't warn them.

</comment></comment></comment><comment><USER9> If you're going to write an article with highlighted, bolded, enlarged exerpts to distract me from the main text, could you _please_ put those exerpts in the right place? It's really jarring when I'm reading something about health insurance only to be interrupted with some segue about dietary studies that would have been more relevant 10 paragraphs earlier.

</comment><comment><USER10> Regarding #3. The advise I get from my family (5 people in the medical field) is that hospitals will kill you. You go to the hospital to fix your problem and get out as fast as you can. You will heal faster at home and you will sleep better too.

<comment><USER11> this. I broke my ankle a few years back and needed surgery, the staff in the recovery room were surprised that I discharged myself the same day rather than stay overnight, and didn't look especially happy when the reason I gave was that I didn't want to get sick.

</comment></comment><comment><USER12> _" First of all, some studies are just poorly designed or hopelessly biased. Second, even the best individual studies have their flaws and limitations. This isn't because all science is bad or untrustworthy. It's because it's an iterative process, and it takes many studies to get at the truth of the matter. Individual studies will almost never give the final word on a particular question. That's just how science works."_

It's pretty basic, but I think a lot of people lack this insight and it causes them to lose faith in all of science when they see contradictory studies.

</comment><comment><USER13> Medical friends here advise against the modern day trend of getting lots of tests "just in case" \- even routine scans in healthy people can flag up unrelated stuff, which then causes stress, and potential for unrequired further tests and invasive procedures. One chap in the office went in for a well-man scan, ended up thinking he was going to die due to a tangent one doctor took him on (turned out to be a boring congential thing; he was perfectly healthy with it).

When you have a problem, sure, get it checked. But, don't go looking for problems and tests for problems!

</comment><comment><USER14> I don't understand the title, this writer performs the act of "getting healthcare is dangerous" after she reports on healthcare?

I get that she "stops dieting", which is something different, I guess, from her normal behavior, and sure, the writer probably does start ignoring new health studies after reporting on healthcare, but then the list of seven things becomes just paragraph titles, completely unrelated to the original heading of the story...

I'm all for grabbing extra pageviews, but this format wasn't well executed, given the content.

</comment><comment><USER15> One a similar note I recently spent a few hours trying to figure out if saturated fat is ok or not and whether coconut oil is healthy.

(I still have no clue)

<comment><USER16> Consider this: many diseases correlate strongly with obesity.

Obesity correlates strongly (well, causates, but causation -> correlation even though correlation -!> causation) with calorie consumption.

Calorie consumption correlates strongly with food consumption of all types.

People who eat more (saturated fat | coconut oil | salt | carbohydrates | fat | protein | the brain tissue of Emperor Penguins that have naturally died) tend to eat more food, which leads to obesity, which leads to health problems.

Basically more studies need to control for obesity. It's appalling how few do.

</comment></comment><comment><USER17> Wow, this made me realize journalists can really write about anything without being concerned about spreading harmful, false information. I don't get the feeling the author has gained a more responsible approach to writing, just fresher blurbs to put in their health articles.

<comment><USER7> >>without being concerned about spreading harmful, false information.

So exactly which part do you think is "harmful" and "false"?

</comment></comment><comment><USER18> I like the "stop dieting" and graph about what causes vs protects against cancer. The "don't get healthcare" is ridiculous though. But then again, especially in the US unnecessary back surgeries for example are insanely common...

<comment><USER19> Read it carefully - the chart implies roughly equal weighting between 'cause' and 'prevent' for some foods, but the axes are scaled very differently either side of the dividing line.

<comment><USER20> I believed they are scaled equally. Each 'step' from the middle indicates an increase or decrease in risk by a factor of 2. If you're at 0.5, you're half as likely to get cancer; 2, twice as likely. 0.1 is 10x less risk, 10 is 10x more risk.

The graph was also created by Vox and includes the words 'cause' and 'prevent' for exaggeration, but the individual studies mostly imply correlation.

</comment></comment></comment><comment><USER21> Pro tip: If you're going to pull out the "combined experience" cliche, anything less than 25 years just emphasizes how little experience that is.

</comment><comment><USER22> >Before we started reporting on health, we had no medical training.

If I already knew these seven things, am I qualified to be a healthcare reporter for Vox?

<comment><USER23> After seeing the quality of a few articles on that site, you may be _over_ qualified to be a reporter for Vox.

</comment></comment><comment><USER24> I'm dubious about the "over-screening" problem. At the moment it may be that we would overreact to every pre-cancerous spot. But surely once we're used to screening and have done the studies over years, we'll know which cancers can be ignored and which ones need to be treated. [This assumes of course that whole body screening can be made very cheap and easy]

<comment><USER25> Look at the thyroid cancer graph: over twenty years the detection rate has increased by about 15x without any concomitant decrease in mortality.

With any diagnostic measure, you must ask whether the information it produces is actionable. If anything, they way you've phrased it is backward: _first_ we find a new treatment (via research) and once it gives us an action to perform, _then_ we can justify the screening. If catching a cancer earlier helps, screen. If not (prostate or breast screenings too early in life), don't.

Obviously if you have family history, risk factors, or something with high specificity like a BRCA mutation, you treat. But many of those things are discovered with a simple history/physical (H&P), which is _the_ important screening your primary physician should be performing.</comment></comment>


Go West young MBA important rules for building wealth in San Francisco - <AUTHOR> http://pandodaily.com/2012/11/21/go-west-young-mba-important-rules-for-building-wealth-in-san-francisco/

<comment><AUTHOR> So I posted this not because I support the post, but because I first took it as satire, but learning from the author and editor that it's meant seriously, I find this horrendously cynical and offensive as someone who is a repeat startup founder. Maybe I am missing something but I cannot buy the idea that startupland benefits from MBAs following this advice from the post:

"Calling or emailing the CEO of a startup — even though he is a complete stranger — and insisting that he meet with you so that you can tell him why his company is fucked without you being part of his life, then demanding a compensation package rife with equity from his ESOP along with a market salary may appear far-fetched…"

Parasitic if you ask me. (and unlike some folks on here I'm a huge fan of PD and find them to be far more startup/entrepreneur friendly than most of the tech media)</comment>


URL design for an HTTP API - <AUTHOR> http://stackoverflow.com/questions/4409877/url-design-for-an-api Hi HN, I know there's some very smart and experienced developers out there, so I'm double posting here hoping I'll find a good solution to this.<p>Thanks for your help ! <comment><AUTHOR> I know there's some very smart and experienced developers out there.

So I'm double posting here hoping I'll find a good solution to this.</comment>


Designer, Developer, and Maker (Portfolio Review) - <AUTHOR> https://crouther.github.io <comment><AUTHOR> I'd like some feedback on the styling, coding and overall layout of the page. Are there any suggestions, changes, or enhancements you'd make personally?</comment>


Seattle's University Bridge still operates on Compaq 8080 and 5.25" Floppy disks - <AUTHOR> http://www.seattlebikeblog.com/2014/03/12/no-more-5-12-floppy-disks-university-bridge-openings-will-take-longer-as-city-updates-computer-wiring/ <comment><USER2> The original article is much more interesting and informative: [http://blogs.seattletimes.com/today/2014/03/seattles- univers...](http://blogs.seattletimes.com/today/2014/03/seattles-university- bridge-undergoing-a-reboot/)

It also includes a picture of the computer: [http://i.imgur.com/oK0eknm.jpg](http://i.imgur.com/oK0eknm.jpg)

<comment><USER3> Appears to be a Compaq Portable II, which is a 286 PC clone, not an 8080.

[http://oldcomputers.net/compaqii.html](http://oldcomputers.net/compaqii.html)

[https://en.wikipedia.org/wiki/Compaq_Portable_II](https://en.wikipedia.org/wiki/Compaq_Portable_II)

<comment><USER4> Yeah, 8080s never ran MS-DOS. The original IBM PC, for which MS-DOS was written, had an 8088 procesor.

<comment><USER5> The original Compaq Portable that my family had growing up ran Compaq DOS, IIRC.

<comment><USER6> Yes, but it had an 8088, not an 8080.

</comment></comment></comment></comment></comment><comment><USER7> _" you probably would have assumed there were sophisticated systems at work."_

That bridge was built at the turn of the century. I'm surprised to hear there's a computer involved at all.

<comment><USER8> Wasn't the turn of the century only 14 years ago?

<comment><USER7> Touché. Just used that phrase out of habit. I was (hopefully obviously) referring to the century prior.

<comment><USER9> I enjoy referring to DEC and CP/M machines as turn of the century computers :-). But the recent turn has left us with a linguistic equivalent to the Y2K problem, which in itself is amusing in its own sort of way. :-)

</comment></comment></comment></comment><comment><USER10> Much of our infrastructure runs on old computers. That's not necessarily bad. Assuming there's no network connection, configs are left unchanged, and updates are not installed, neither bitrot nor vulnerabilities will bring down the system. A hardware failure could, if compatible replacements aren't available. The latter does occur.

Part of the reason for keeping these old systems is the risk in upgrading. The software has been in service for years so it's relatively battle-tested. New software comes with the risk of bugs and deployment problems. Bugs and deployment problems can mean lengthy shutdowns of critical infrastructure (if it proves impossible to bring the old system back into service as an emergency measure).

So there is some wisdom in letting the old systems clunk along. Up to a point, that is.

</comment><comment><USER11> I was waiting for the U-Bridge once at about 1am, and I had another ~14 miles to ride on my bike before I got home.

For about 15 minutes, the bridge would open, almost close but then stop with one side about 2 feet up.

I was NOT looking forward to riding around to another bridge.

Another cyclist rode up, watched one of these cycles, and then he looked over at me and shrugged, rode up and did the ~2ft drop w/o incident.

I gave it about 30 seconds, looked around for cops and then went over myself. It was one of the scariest things I have done, and I was just hyper-aware for the rest of the ride home and woke up my housemates to tell them this story.

<comment><USER12> The Ballard Bridge has been getting stuck more and more in recent months, it seems.

And the University Bridge (or maybe it's Montlake) needs to get hosed down with water every hour on hot days, or otherwise it will expand and be unable to lift.

Welcome to Seattle.

</comment></comment><comment><USER13> In the early 90s I saw a control system for a destructive ammunition test center being run by a TRS-80 Color Computer I. They wanted to know if I could update the software and handed me a thick greenbar printout of assembly code. I didn't take the gig.

<comment><USER14> What? And pass up the joy of writing 6809 assembly language? (well aside for the 6809, the Color Computer was terrible).

<comment><USER15> OS-9 was another of the non-terrible things about the CoCo. It probably wasn't running OS-9, though.

</comment></comment></comment><comment><USER16> "If it ain't broke, don't fix it." \- Bert Lance

<comment><USER17> "If it ain't broke you still have to upgrade, because delay in doing so will bring compatibly nightmares upon you" \- Ivanca

<comment><USER18> Compatibility with what? It's not being upgraded because _it works_. There's a reason that most POS systems still look like something out of Tron. They work, they're battle hardened, and they're fast. Upgrade to some new system and only if you're a glutton for pain (unless you have to absolutely change systems for some reason, then you're just forced to be in pain for a while.)

<comment><USER19> and when a component breaks?

<comment><USER16> If it breaks, you surely need to fix it (and having plans to fix it or upgrading it due to lack of replacement parts etc is of course neccessary). However, there is also inherent risks in upgrading such appliances, so it should not be done simply because the hardware is old.

<comment><USER20> From the original article:

> The old-school electric resistors and other parts are wearing out, so that > replacements must be scavenged from city shops or eBay, he says. Finnick > recalls a 12-hour stoppage, when the city used a backup diesel motor to lift > the bridge for boats. Other times, the city dispatched a second bridge > tender to help open the bridge manually.

It does break and replacement parts are hard to find.

</comment></comment></comment></comment></comment></comment><comment><USER21> You can still buy 5 1/4" disks, because I do.

<comment> ezequiel-garzon I'm curious, why do you use them instead of CDs, DVDs, external USB drives, etc?

<comment><USER22> CDs, DVDs and USB sticks don't fit in a 5 1/4" disk drive.

<comment><USER23> Excellent answer Blahah.

Now, gaius, why do you need to use a 5.25 inch floppy disc drive instead of a more recent storage medium?

If the answer is something along the lines of 'because that is all the old computer can use' can you clarify if this is a retro hobby or an actual use case?

<comment><USER21> I like to see how much real work I can do on 8-bit hardware, e.g. BBC micros, VIC 20, so a bit of both. For example I plan technical dives using Buhlmann in 6502 assembler, printed on a dot matrix.

Come the infocalypse, everyone will work this way.

<comment><USER23> gaius, I worked that way for years! BBC Master with coprocessor and all for general word processing and maths teaching.

Before that an Apple II and 5.25 inch disc drive used to control the temperature of a cryostat and log data.

</comment></comment></comment></comment></comment></comment><comment><USER24> The PC seems alright to me (after all, how much CPU do you need to open a bridge...), but the floppies seem a bit fragile and unreliable, they lose data pretty fast.

<comment><USER25> That's what I'm thinking too. The fact that it's old and running MS-DOS doesn't seem like much of a big deal to me considering it's not networked and only has one job to do that it's already capable of doing. They should probably just go get a cheep IDE HDD, copy the floppy onto it and boot from there. But other then that, I don't see tons of issues.

This does however seem like a fairly obvious use-case for an embedded solution. No floppies, no moving parts, etc.. It would last much longer then this computer will. It's not like the computer was doing much anyway (I mean, besides signaling motors, I'm not really sure what the computer was even doing).

<comment><USER26> An IDE Flash drive would be even better, they are pretty cheap as well.

<comment> mark-r I had no idea IDE flash drives existed until you said so, but indeed there's quite a few. Just for situations such as this probably.

</comment></comment></comment></comment><comment><USER27> Does anyone know what they are going to replace it with?

Please tell me it's not a desktop computer again, with rotating disks, fans and all those lovely things that, you know, fail constantly.

</comment><comment><USER28> I got a tour of the Burnside Bridge in Portland twice when I was in probably middle school, a couple years apart. The first time, the operator had a big panel of giant switches and buttons with a relay interlock system to make sure things proceeded in the right order. The second time, the control system had been replaced by a single color LCD touchscreen with what I can only describe as the bridge opening wizard... complete with a "Next >" button.

</comment><comment><USER29> The long term sustainment / archival aspects of this are really interesting. With the new replacement system, is the company just rebuilding it from scratch? Are there design documents or source code they have access to from the old system? Is the new company going to be required to escrow similar design elements?

</comment><comment><USER30> I'm mostly surprised it's a personal computer and not a relay network like elevators were/are typically controlled by. [http://www.youtube.com/watch?v=5GevDdd_IOY](http://www.youtube.com/watch?v=5GevDdd_IOY)

</comment><comment><USER31> I remember an old IEEE article on the NYC subway system. There were portions of the system that was built in the 1900's that still controls the tracks. The MTA was afraid of removing the old system because they had no idea how it worked.

</comment><comment><USER32> blog spam.

<comment><USER33> click 'flag' button

</comment></comment><comment><USER34> Better to replace it with an embedded controller with no moving parts. Buy a couple of these and flash them with the same firmware and replace the whole thing if it ever dies.

</comment><comment><USER35> Heh, I literally just biked over the University Bridge.

If you think that's old, you should see what our transportation infrastructure (stop lights, loop detectors, etc.) run on.</comment>