Ask HN: Current state of programming embedded devices? - <AUTHOR> Hi,
I recently switched to a hardware company and we are working on a medical device. We need a nice, touch-based user interface on a 5"-10" inch display. Some math calculations in the background, but no realtime stuff. I am an experienced developer on different platforms but I never programmed an embedded device.
What is the mainstream OS on embedded devices right now? Linux, Android, Win 7 Embedded? What about Windows 10 IOT?
What is a good setup? Rasberry Pi + official touch screen? Are there medical grade devices out there (doesn't matter if it is expensive)?
What about developer tools? Okay, Visual Studio for windows? But what about the other platforms? Still C?
You see, I'm pretty clueless, so any help is much appreciated!
Thanks. <comment><USER2> I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people.

The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.

<comment><USER3> _We used Linux /C so we didn't kill people._

I'm not sure that C the best language for life critical high level applications... it's far too easy to shoot yourself in the foot.

<comment><USER4> What alternative would you recommend?

<comment><USER5> Pretty much anything!! Java, C#, Rust, Go, OCaml, Lisp, ... even C++ would be a much better choice.

Check this out: [http://tobyho.com/2008/03/30/how-safe-is-your- programming/](http://tobyho.com/2008/03/30/how-safe-is-your-programming/)

There also used to be a website that ranked programming languages according to various parameters (which is faster, which is safer) by asking visitors pairwise comparisons (Which is faster - Matlab or C?). I was going to link it but can't find it unfortunately. Anyway I'm pretty sure C would come second- last in the safety ranking, right above assembly.

</comment></comment></comment></comment><comment><USER6> I work in scientific equipment, and there is a huge trend towards devices containing a touch screen with some amount of computing power. I take a look at what competitors are using, and have opened up some gadgets. The two main things for newer equipment seem to be:

* Android, when the product offers a host of mainstream computing features. I think the rationale for going with Android is: "The user already knows how to use it."

* Linux, when the product is cheaper, and has a more bare bones or restricted function set. I don't know for sure, but I think that a Linux build can be more stripped down. Little boards like Raspberry Pi and BeagleBone abound, and if nothing else, you can create a nice proof-of-concept with one of those. I've actually done this, writing my code in Python, with the expectation that the "real" programmers would turn it into something else.

I'm not in the skill areas that actually develop this stuff, so I don't know any lower level details. My job tends to be supplying the theory of operation for the actual measurement.

Both systems use SOM's (system on a module) that are typically sold with the software tools to get you started, such as a working demo OS. It is rare to see real-time stuff done on the main computer. Since you're usually talking to some sort of device hardware anyway, it's usually more convenient to put the real-time stuff on a separate microcontroller, that's got little or no interrupt overhead to deal with.

<comment><AUTHOR> Yep, I bought a SOM for testing. It can run Linux, Android 4.4 and Windows 7 Embedded. Windows was pre-installed so I gave it a test-run and it looks and feels very 1990s. Hence my question.

<comment><USER6> There was a previous generation of products that used embedded Windows for the same reason: "The user already knows how to use it," plus there was the hope of being able to transfer Windows programming skills and tools to the embedded target.

</comment></comment></comment><comment><USER7> I don't want to sound too negative but If you have moved to a hardware company then the resident Electronics Engineer (EE) should be determining much of the embedded hardware configuration.

Sure the choice of CPU architecture, OS, GUI Widgets etc will/should involve you but hardware choice is determined by user requirement, gui, reliability (watchdog timers, failure modes), power requirements, BOM Costs/long term availability, IP Ratings, enclosures, emi, electrical safety etc and is a totally different discipline which you need an EE and can seriously backfire and not get approval if not done correct.

Saying all that working as a programmer in a hardware business will teach you a lot of the above and give you a bigger influence in future projects.

<comment><AUTHOR> Thanks, but the Electronics Engineer will ask you what you'd like to run on this device and then pick a suitable piece of hardware. Cost is not our biggest concern.

</comment></comment><comment><USER8> Depends on what reliability / response time / etc. you need. The requirements you list are not very specific. You should also look at what interaction you need and what kind of regulation applies to your device (since it's a medical setting, this may influence your choice).

You can potentially go with bare microprocessors and something like [http://femtoos.org/](http://femtoos.org/) to just small ARM devices with windows. You can do everything on one chip, or split the device drivers onto separate chips and drive them over I2C where specific timing is crucial.

There are many options - I'd start with listing exactly what you need to support (display, io, inputs, timing, single/multi chip, what timing / other guarantees, hardware watchdogs, failsafe states, etc.) and then choose hardware/software based on that.

If you want to produce many devices, I'd stay away from consumer devices like RPi. Simply because you may get stuck with a supply shortage. You can pretty much always order 1k of popular chips, even if it's a shipment from Asia. You may not be able to do the same for a popular RPi model. Also some RPis will get phased out / discontinued at some point and for a medical device you may need to recertify the new model before release.

</comment><comment><USER9> I work at a medical device consultancy, but we're mostly developing custom Class B/C devices at the bare metal level. It sounds like you'll be developing a Class A device and cost isn't a huge issue so I'd probably recommend going the Android route. Find a reputable supplier who's worked with medical devices before, and check their availability guarantee (since the production lifetime of most Android devices is short).

Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.

</comment><comment><USER10> I work at a company that's in the food industry.

Currently, we're running Linux with Qt 4 on PowerPC.

We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs.

We're moving away from Qt for the GUI. HTML5 is the way of the future. ;)

For people who are starting out, I'd recommend using Yocto. It's a build/development environment for embedded Linux. Look it up.

Edit: By they way, if it's not real-time critical, there's nothing stopping you from using any programming language you like except how difficult they can be to cross-compile.

For hard real-time stuff you need a dedicated rt system and you'll have to use C, C++ or maybe Rust.

For soft real-time stuff you can get away with RT-patched Linux. Any language with GC is generally bad with the exception of Erlang, Go and Nim; where the GC is optimised for low latency rather than bulk through-put.

<comment><AUTHOR> Why are you moving away from Qt?

<comment><USER10> A few reasons:

* It's easier to find people with JS skills than C++ skills

* It takes ages to build Qt and it's unreasonably hard to compile. Building the Linux kernel is far less painful.

* It takes ages to build a single Qt project and we have multiple architectures to deploy to (ppc, arm, x86).

* Remote connections are trivial. People only need a browser to connect remotely.

The people at the company who have been using it like it a lot. They just have to put together a few tags and _boom_ there's your GUI.

The GUI has access to some system variables via WebSocket. We have a two-way binding abstraction so people don't have to think too much about events and such.

I wouldn't recommend HTML for a small company though. Better stick to Qt if you're a small group of competent C++ programmers.

<comment><USER11> Is most of your gui simple forms and data? I've done critical care monitors and photobooths, and both seem too complex for html to me. I'd be afraid the HTML would be too slow to process and display, too eager to show scrollbars, too likely not to be optimized for the embedded gpu, etc. Have any experience there? The last time I tried going higher level I tried embedded flash, and that was too limiting.

</comment></comment></comment></comment><comment><USER11> Forget everything you think you know. RPi is great for hobbyists but not what you want to put in your final product, or even really your prototype. Others have already mentioned the reasons. In web development, a commercial-quality stack and a hobbyist stack are essentially the same. With embedded development, they're far different and the commercial stack is still largely vendor-driven.

Call up TI and Freescale, let them know what you're up to, and they'll come demo/loan a few products. Talk to their engineers about your product at a high level so they can immediately drill in on a few options, then talk about hard requirements and even personal preferences/interests and they'll be happy to make recommendations on hardware, OS, language. The naming schemes and jargon can get confusing and features seem to overlap, so make sure to ask lots of questions.

Oftentimes the CPU will determine your OS; some will be more stable and have more complete drivers on Windows, some on Linux, some on specialty OSes. Of course you could take the Linux Kernel and tune it yourself, but unless you really know what you're doing that's not going to be the easiest route. Oftentimes you'll come across sites/videos showing how to get unsupported OS A to work on CPU B and get excited. Ignore those, as what the video _doesn 't_ show is all the things that still _don 't_ work, and that rabbit hole goes deep.

In general for your first project try to avoid straying too far from the beaten path and the recommendations you get from your vendor.

<comment><USER11> In addition, if you're still reading this, be ready for this to be not-the- most-interesting software project. Most of it will be reading vendor documentation and hunting down config errors. And compiling. And figuring out FDA stuff.

Coding-wise you probably won't learn a whole lot. You'll be using old technology and likely limited from using any fancy techniques you want to cook up. Accept that in advance. Thrive in that actually; force yourself to take the safe road software-wise so you can take the time to read through FDA docs and understand all the lingo better. Also spend time with your EE and learn more about that side of the coin. Spend time with the customer-facing side and learn the market. Learn some actual medicine so you're seeing the device as a tool rather than as a platform. All this stuff is way more valuable in the medical field than knowing the latest five JS frameworks (or Haskell plugins, or ruby test platforms, or whatever software-y stuff floats your boat).

<comment><AUTHOR> Yes, I'm still reading this and I'm not afraid of working by the rules (or learning them). I'm just surprised how fragmented the whole embedded device stack is. The whole software development process could (and should) be more defined. Let me gather some more experience and see if I can come up with something more clever :).

</comment></comment></comment><comment><USER12> In today's world, a truly embedded device implies an original firmware driving all the hardware on the device.

These are not so common anymore. Most devices use existing OS platforms depending on the task. \- time/resource critical? real time OSes \- GUI/multimedia/telephony? Android \- a platform for you app? Linux

Dev tools are very dependent on the hardware platform. C is common, as is C++. This is also very vendor specific. Intellectual Property add-on's for different micro's, etc.

You really should consult an expert to get guidance - you can probably do the work yourself, but making the right initial hardware choices matching the requirements will help get everything else right afterwards. Once you have hardware chosen, the rest will fall into place.

I work at a research and design firm, our projects are making custom hardware for people who don't have the expertise or time. Our most frequent customers? "We got this started and now ..." Save yourself the headache of getting half way into the project and discovering a problem you can't solve, then need to hire a consultant to fix it, which will entail redoing and eliminating features because the initial decisions won't support the desired outcome. Make a consultation, and get set on the right path from the start.

<comment><AUTHOR> I already talked to a bunch of consultants and everyone has a different "right path". Hence my question here to get it in front of a lot of experts.

</comment></comment><comment><USER13> The current state is that there is no real current state of programming on those devices. In the real embedded device field (things that need to be cheap but still need to fulfill mission critical tasks with more or less realtime requirements) you have choices between lots of CPU architectures, dozens of realtime OSes or directly going the bare metal route and you will mostly develop in C (or maybe a subset of C++ - I guess most embedded compilers are still not up to C++11).

Depending on your safety and realtime requirements you might be very restricted on component choice as well as coding style. E.g. for a deterministic system no heap allocations might be allowed. I guess that should be the case for most medial devices.

However your project sounds more like an embedded device in the sense of "user can't modify it", but it is still running some PC/Smartphone like applications. For that kind of stuff Android and Linux are often seen (in order from most-consumer like to most realtime capable). You get the benefit of being able to reuse standard drivers, frameworks and applications but being able to guarantee that it will always work is basically impossible.

Many devices therefore also use a multi-cpu architecture, where the criticial stuff is running on a microcontroller with RTOS and the fancy UI is running on a speedier SOC with a normal OS.

QNX and GreenHills Integrity are somewhere in the middle, by providing a realtime OS which still incorporates some consumer features and are often chosen if a realtime device should directly draw UI.

You should checkout the detailed requirements for your projects and what would be possible and accepted. I guess medical has some quite strong regulations for certifications. And I'm sure using normal consumer chips (no extended temperature range, no certificated manufacturing process, ...) will always be not possible.

<comment><AUTHOR> > The current state is that there is no real current state of programming on > those devices.

Yes, that's what I suspected but I feel there _should_ be some advices/best practices.

<comment><USER14> I wonder if there are any industry-focused resources (meetups, mailing lists, etc.) available, to offer specific guidance.

</comment></comment></comment><comment><USER15> The mainstream OS choices are: Wind River VxWorks, Green Hills Integrity, BlackBerry QNX, Linux, Android, and (god forbid) some variant of Windows.

A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)

<comment><USER16> Can I ask why you dislike dynamic languages in an embedded environment? Or why you think they are 'not good'?

<comment><USER17> Dynamic languages have unpredictable usage of memory. This is okay when you have many gigabytes of memory. This is not okay when you have a handful of _megabytes_ (or a single gigabyte) of memory.

Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer.

Also, static languages are usually faster and more predictable, to a certain degree. This is advantageous in an industry that would rather spend years developing something than have a small chance of killing someone. Bugs are unacceptable.

If you're willing to pack an Intel Atom or something into your device, fine. But if you can get by with a tiny ARM chip, why shouldn't you?

<comment><USER3> _But if you can get by with a tiny ARM chip, why shouldn 't you?_

Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.

<comment><USER17> ARM chips have feature parity with Atom chips except for their x86 architecture and power. ARM chips and their implementations are _less_ complex, not more. Software components can be a bother, but ARM runs Linux perfectly well. If Linux doesn't suit your fancy, there are plenty of RTOS waiting for you.

And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions.

Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it.

And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field.

(But to each his own, of course! You can do awesome things with any tool.)

<comment><USER3> Complexity refers to overall cognitive load, hassle and lead time for developers and the business as a whole (hardware sourcing, cross-compiling, testing, etc.) and not just chip features.

Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.

</comment></comment></comment></comment></comment></comment><comment><USER16> I'd go with a Raspberry Pi or other linux supported board. Particularly for prototyping.

If you're looking at building an interface, are you considering web-based?

I'm going to plug my own little project here, I'm also new to embedded development, but hate how everything is hard-coded to the platform you build on. I built a hardware agnostic library to make it easy to run your business logic on different hardware. It's in javascript (I've asked anonymous_ian why he doesn't like dynamic languages in embedded). [http://getfavor.net](http://getfavor.net)

Keen to hear your thoughts.

<comment><AUTHOR> It's a good idea but I'd be worried it isn't "snappy" enough on (somewhat slow) embedded devices.

<comment><USER16> I think it depends on the application, I agree it isn't for everything.

What I find a bit funny about some embedded stuff is that I don't think performance is always as important as in other systems.

Consider something like Nest. If it takes 50ms or 500ms for the thermastat to respond, what is the implications. Compare that to a webpage, and all of a sudden, performance isn't a prime factor. Another example is a decibel meter I'm currently building. I need it to send data to a server when sounds reach above a certain level. How important is performance in that scenario. As well as things like Amazon's nifty little ordering button, I'm quite sure performance doesn't really matter on that.

So, in devices where performance is a primary concern, at the moment, javascript probably isn't the way to go. Though, with progress in things like asm.js, that may change in the near future too.

I'm not suggesting this is the tool for everything, but as I look at it, IoT probably has fewer use-cases where performance is a primary concern than other environments.

Of course, probably all safety systems, self-driving cars, drones, etc. etc. are not recommended to be done in JS... yet.. :)

<comment><USER18> For the thermostat it could well depend on the context to how much the latency matters.

If your recording average ambient temperature it probably doesn't matter much. If instead it is part of a physics experiment it could matter a lot. If it is part of some industrial control system [1] it could be critical.

For the ordering button the time taken doesn't matter, but the less time it takes (especially with the wifi hardware), is going to be a factor in how much power it consumes, and therefore battery life.

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

</comment></comment></comment></comment><comment><USER19> Reading these comments tells me that the state of embedded programming is as strong and as fragmented as current web development.

My company uses VxWorks, MQX, Android, Windows CE and Linux. We're dropping VxWorks because it's costly and cumbersome. MQX is being replaced by whatever Freescale/NXP is pushing now, we put a lot of resources into the older version of MQX and aren't following them into their new incarnation. We use Android for special devices, but it seems to take a good amount of work to put it on custom hardware.

The OS that makes the most sense for embedded work nine times out of ten is Linux. It's widely used, documented enough, and has the most vendor support.

A good setup? You can get an AM335x EVM with an LCD, which is the same processor as a Rasberry Pi. I believe i.MX6 has an EVM with an LCD as well. Bottom line, you should talk to vendors, to see what they have to offer. Since it sounds like you have limited experience in this area, working with a vendor that will give you support is probably the most important thing.

Your developer tools are entirely dependent on your OS and chip. Ultimately, doing embedded work you're most likely going to use C/C++, but if you're on Linux or any modern operating system, then you have the ability to use a scripting language.

</comment><comment><USER20> I recently implemented something like this, albeit for a research-use-only device. We used an embedded intel board with separate PCAP touchscreen connected to the LVDS+USB interface. X.org supported it out of the box. Out product runs on linux/C++ with html/js UI. There are a couple of embeddable web browsers. I've been very satisfied with a simple X11 browser based on Chromium embedded framework.

PCAP touchscreen worked well with double-gloved fingers and there are touch controllers that will reject a stray water droplet on the screen.

I'm not sure about the OS considerations for medical device use, but for linux you might consider the yocto project, which is designed for this kind of stripped down deployment. It will limit the number of moving parts you have to validate. If you're less devoted to the open source route, check out QT's boot-to-qt offering. QT ui's are common in this field and I believe there are supported boards at a range of price points.

You wouldn't want to hitch your design to Rasperry Pi or Beaglebone or such because of the short support lifetime of individual models and components. Part of what you pay for with the industrial vendors is a commitment to supply the system for 5-10 years.

If any of this is helpful, drop a note using the email in my profile.

</comment><comment><USER21> Hi, I made a few devices like that in the medical sector. Back then it was Windows CE, today Linux would be the way to go i guess. If you are like me, using Raspberry pi & co after decades of windows development, check out VisualGDB. Microsoft recently released a similar product as native Visual Studio Plugin. I understand they plan to support cross compiling as well. That will be so awesome.

<comment><AUTHOR> no one tried Win 10 IOT yet? ;)

</comment></comment><comment><USER22> We used an Android tablet for the UI here: [http://www.centervue.com/productdb19.html?id=919](http://www.centervue.com/productdb19.html?id=919)

Other stuff is separate.

<comment><AUTHOR> that looks great. And you used C++ or Java?

<comment><USER22> Android is programmed in Java. Other parts of the system were done with other languages.

That architecture worked for us - it may well not work for other needs, depending on communication latencies, costs, and so on.

</comment></comment></comment><comment><USER23> You may be interested in reach technology's display modules. You program the GUI and send it some commands and it will display whatever you want. You can write some really snazzy Qt touch widgets. I interned for these guys a couple years ago and it sounds very similar to what you're asking for. [http://www.reachtech.com/](http://www.reachtech.com/)

</comment><comment><USER24> This is a framework for medical software development, they have a few papers talking about the experience and benefits :

[http://www.lambdanative.org/](http://www.lambdanative.org/)

</comment><comment><USER25> Raspberry Pi isn't an enterprise/medical grade device in my opinion. I wouldn't want to have a SD card as primary storage either.

Do you need to integrate a lot of sensors or have a lot of IO?

<comment><AUTHOR> No, data generation and collection is done by other components. I only need to send a start signal to those (through USB). This is only for UI.

<comment><USER11> You may want to consider something like rs485 instead of USB. One less attack vector for bugs and viruses. Or users plugging in mice or whatever and expecting them to work.

</comment></comment></comment><comment><USER26> usage of the Leap motion controller should actually be encouraged more, right here!

</comment><comment><USER27> I don't think there's any simple answer to your specific questions based on what you've provided so far. I'm going to word vomit a bunch of stuff that might, with some Google/Wikipedia searches, help give you a better view (I hope!). I hope this is helpful.

So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.).

Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these.

You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws).

Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays.

If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes.

Handwavy answers are that your safety-critical stuff is going to be hard real- time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart.

For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on.

I'd recommend the Stanford Biodesign textbook as a one resource to help get up to speed: [http://www.amazon.com/Biodesign-Process-Innovating- Medical-T...](http://www.amazon.com/Biodesign-Process-Innovating-Medical- Technologies/dp/110708735X)

Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant.

Good luck!

<comment><USER28> This advice reflects what I've seen in safety-critical field reading on all kinds of deployments. This plus other comments to use simplest microcontrollers with tiny RTOS or no OS using simplified software. Good advice and good alias.

<comment><USER27> Thanks and thanks. To further bloviate, Tcl is my not-so-secret weapon. I first used it when doing exploratory work with some embedded one-off instruments and it made an impression because those doohickies are still running strong to this day, well beyond the design goal. They had sensors that were communicating over a serial console: Tcl made interfacing quick and painless, and a control GUI in Tk practically built itself. It's robust and a known quantity (flaws and all). There's also some level of je ne sais quoi where, like Lisp, I don't feel like I will paint myself into a corner: need more performance? drop down to C. language is limiting? make a better DSL. So I guess I'm either a fan or delusional (likely, both).

I don't personally know of anyone in medical using it, but your comment about no OS does prod me to say that I have wondered if running Forth on bare metal for medical is viable and/or desirable on a greenfield project. I'm not saying _I_ would do it, but I would happily cheer on someone else. (OP, don't do this, I'm delusional)

And OP, I really hope that my wall of text won't be discouraging in any way. Personally, I found that documentation is (a la Homer Simpson) the cause of, and solution to, all of life's problems in a regulated environment. If you master that, document honestly and eagerly, it's downhill from there and life will be good.

<comment><USER28> I never thought of Tcl to be used in safety- or security-critical systems. It's certainly simple and easy to use. We played with it for agent-oriented programming back in the day. Had serious, design-level issues for security and was harder to parse than some others (eg LISP's).

Rather than just a critique, I'm curious where and how you use it with what benefits it brings you? I could certainly see it in UI or untrusted parts. Maybe also during development in a way that auto-generates C or something that runs in production.

<comment><USER27> I only use it like you guessed (and what I think it's best/appropriate for): gluing things together, embedded scripting, and Tk on internal tools/gizmos and early prototypes. I wasn't clear earlier, sorry.

To be perfectly fair, on the decision matrix Tcl gets a helpful boost due to my own familiarity with it and playing nice with C; if a butterfly had flapped it's wings just a little bit differently or I was starting out today I would probably be using something else. Probably Java. Ada would be great, but the lack of ecosystem diversity makes me apprehensive.

<comment><USER28> Gotcha. Look into REBOL/RED while you're at it. RED is a REBOL clone/modification for system programming. They're LISP like advantages without the parenthesis and having small footprint. RED is already used in one OS project. I keep thinking of modifying it for system use. People keep telling me to check out Nim as it's like Pascal and Python combined with extra safety, macros, and C code generation.

So, there you have it: REBOL, RED, and Nim. Maybe Ivory language from Galois, too, but you need to know Haskell for that.

<comment><USER27> I remember playing around with REBOL a long time ago and it seemed useful and practical, but for reasons long forgotten I never used it. Maybe licensing? RED does look cool and I hadn't heard of it before, thanks for the tip.

Don't have any experience with Nim, but I share your interest for the same reasons. Haskell and I don't get along, maybe I'm too old and set in my ways?

Did you catch the link to/discussion of Little shared on here a few days ago? It might be of interest. [https://news.ycombinator.com/item?id=11530097](https://news.ycombinator.com/item?id=11530097)

<comment><USER28> Me too on Haskell. Mainly plan to try other two. Saw Little but didn't really get it past adoption. Then, your comment led me to the Why page which told me that was _exactly_ the point. Along with programming in the large support. Funnier when I found out the boss wrote that.

I'd say it's not a good language to go with today for same reasons I'd say Tcl isn't. It's an interesting improvement especially to get better syntax with legacy compatibility with field-proven, TCL modules. And TK is still the shit for portable, easy-to-build GUI's. A TCL shop should definitely experiment with it and maybe incrementally upgrade their code. I think I'd be fine with a more typed, efficient, and fixed version of Tcl for some apps. Especially a command shell replacement or prototyping system.

Just not production unless it's non-critical like what you use it for. I don't even use it to glue to critical things as the glue is part of the TCB to a degree. Gotta find close-to-metal, abstract, typed, efficient, and macro'd stuff to replace it. At least we have contenders.</comment></comment></comment></comment></comment></comment></comment></comment>


Knowledge-Based Trust: Estimating the Trustworthiness of Web Sources [pdf] - <AUTHOR> http://arxiv.org/pdf/1502.03519v1.pdf

<comment><USER2> looks way too easy to fool by telling it what it wants to hear</comment>


Show HN: I built a MySQL storage engine which is InnoDB compatible - <AUTHOR> https://upscaledb.com/blog/0014-beta-release-of-mysql-0.0.1.html <comment><USER2> No transactions? Single-threaded? Global lock?

Don't want to put anyone's work down, but at first sight this looks much more like MyISAM than InnoDB - and just like this, MyISAM's a helluva lot faster than InnoDB for single writer workloads throwing ACID out of the window.

Just that MyISAM is battle tested over the course of several years. Again, interested to see what comes out of it, but if history is a lesson, it's usually easier to go from correct to fast (PostgreSQL) than from fast to correct (MySQL et al.).

<comment><USER3> Version 0.0.1 looks much like an experiment in writing a working storage engine. It lacks a lot of critically important things. It's hard to say anything at this point about any real-world scenarios where this storage engine would be useful.

What concerned me a bit was absence of an interesting and promising general idea behind the implementation, the reason to implement a new engine. Maybe it is there, but the blog post does not say anything about it.

<comment><USER2> Exactly this, I was missing the big picture. Having worked with at least a dozen databases, my claim today is that of Tony Million: Don't be a hipster and just use Postgres. Don't get me wrong, I also work with Aerospike, Redshift, Redis and a few other specialized data stores, but I always know _why_ Postgres wouldn't do there. For any specialized data store, at least provide a rationale _where_ the niche is where that thing is better than anything else that's on the market. Simply claiming it's "fast" without further specifications worked out for MongoDB, but I hope it's for the very last time. Optimization means tradeoffs.

</comment></comment></comment><comment><USER4> The upscaledb FAQ indicates "it is not yet concurrent; it uses a big lock to make sure that only one thread can access the upscaledb environment at a time".

InnoDB is designed for concurrency (using MVCC, granular locking, etc) so I'd expect it to be slower at single-threaded workloads than another engine that skips all that.

Only using single-threaded benchmarking is a bit misleading, imo. This is mentioned in the article but only in a small bullet point towards the bottom.

<comment><AUTHOR> I ran sysbench benchmarks with 30 concurrent connections. The performance gap between InnoDB and upscaledb shrank a bit, but not much.

The reason is that most of the performance is spent in MySQL and not in the key/value store, and then it does not make a big difference if the key/value store is concurrent or not.

In my experience the assumption of "concurrent = fast" is a misconception. Right now upscaledb moves certain operations (i.e. flushing dirty buffers) to the background. It is better to have fast single-threaded code instead of multi-threaded code with a huge locking overhead. A compromise would be to move the lock to the database level (instead of the Environment, which is basically the container for multiple databases), and make sure that there's no shared state between the databases. But that actually does not have that much priority for me because I do not expect to win that much performance.

<comment><USER4> 30 concurrent connections is a very low number, compared to uses of MySQL/InnoDB at real scale. What happens at higher numbers?

I am not arguing that "concurrent = fast". My point is real systems have a higher level of concurrency as a baseline.

InnoDB supports granular concurrent access because real workloads need this. Systems that have poor stories around concurrency -- MyISAM, Redis, pre- WiredTiger MongoDB -- definitely hit real scalability issues under high-volume workloads.

</comment></comment></comment><comment><USER5> Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong.

I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood.

So if I was going to use a different storage engine, would want something more than its a bit faster, in some cases.

Having said that, what a wonderful amount of work, and don't stop hacking on it!

<comment><USER6> The most recent break I encountered was ibtmp1 exploding to 100's of GB and killing the box with InnoDB, so I'm not sure "how it breaks is well understood".

<comment><USER7> Funnily enough I encountered something similar years ago on Microsoft SQL Server 2005.

Never got to the bottom of it either.

<comment><USER8> A lot of cases I've seen where tempdb suddenly grows massively is an runaway Cartesian product in a query. Sometimes this is intentional but was never expected to be used on large data, but usually it is accidental and worse an inexperienced DB person has "fixed" the problem with multiplied output rows by adding "distinct" instead of fixing the query logic properly.

</comment></comment></comment></comment><comment><USER9> Stopped reading after no transactions. Theory question: musn't transactions reduce necessarily performance?

<comment><AUTHOR> Not necessarily. I ran sysbench with InnoDB and manually switched off transactions, and it was a lot slower. I don't know why - didn't look into it.

upscaledb _does_ use transactions. I.e. if you insert a row with a primary and a secondary index then upscaledb inserts two key/value pairs in two databases. All these operations are wrapped in Transactions. They are just not yet supported on SQL level.

<comment><USER10> In InnoDB everything is a transaction. If you do not begin/commit then each statement will be its own transaction.

Batching a group of statements together in a small transaction is usually better because it reduces log flushing. ACID only needs to be guaranteed on commit. Similarly, applying transactions in parallel is faster because of group commit.

</comment></comment></comment><comment><USER10> MySQL Product Manager here. Any feedback on the Storage Engine API?

<comment><AUTHOR> It's ok! The example storage engine could implement more functionality, just to demonstrate i.e. how rows are serialized/deserialized etc. The test suite was very helpful.

</comment></comment><comment><USER11> My physics teacher would have slapped those diagrams around my head asking "Is the y-axis 6000 apples?"

</comment><comment><USER12> I think this could be pretty neat, it'll be interesting to see how it evolves. However, looking at the comments people have left here I would suggest putting up a table/comparison with InnoDB side by side, detailing which features are implemented, which are not and which are but aren't available through the SQL layer yet.

This would also put the "compatible with InnoDB" thing in perspective for people and potentially clear up some other confusion.

</comment><comment><USER13> Label your axes!

</comment><comment><USER14> This looks pretty sexy. Are there atomicity guarantees?

<comment><AUTHOR> BEGIN/COMMIT is not yet supported. But that's on my TODO list.

<comment><USER15> Ulp. The whole point of the InnoDB engine is that it supports atomic transactions, even over crashes. If you want an unsafe table, there's the ISAM engine, which is faster.

What does "100% compatible to InnoDB" mean here? It's not functionally compatible and it's not disk-file-format compatible.

<comment><AUTHOR> If that's your definition of atomicity - yes, upscaledb offers atomic operations. If you define atomicity as the "A" in "ACID" then no - BEGIN/COMMIT wrappers are not yet available. Work in progress!

<comment><USER16> So what you're saying is that in general, transactions are implemented, but the begin/commit syntax for transactions is not yet supported?

<comment><AUTHOR> Correct.

<comment><USER14> Well I think this is very cool. I actually have a project in mind that I think might benefit; I'll look to see if I can use Upscale.</comment></comment></comment></comment></comment></comment></comment>


Mysterious Visitor, Clad in Fur, Puts Paris on Edge - <AUTHOR> http://www.nytimes.com/2014/11/15/world/europe/tiger-wildcat-paris-disneyland.html?ref=science

<comment><USER2> I'm almost certain that it's a hoax...</comment>


Bitcoin is Unsustainable? - <AUTHOR> http://motherboard.vice.com/read/bitcoin-is-unsustainable <comment><USER2> The mining farm linked in that article is from last year. A more modern one is shown here.[1] This new one is located in a cold, mountainous part of China next to an underutilized hydroelectric plant, so they have free cooling and cheap power. They've been able to avoid cable clutter; their power distribution uses aluminum busbars, and they seem to have an in-house network that doesn't require vast numbers of long cables. (The data rate for a Bitcoin miner is very low; you only need to talk to it when setting a new block starting point and if it finds a block.)

[1] [https://bitcointalk.org/index.php?topic=1072474.0;all](https://bitcointalk.org/index.php?topic=1072474.0;all)

<comment><USER3> That link is absolutely fascinating and a very honest account.

</comment></comment><comment><USER4> How can the author write this entire article without mentioning the real numbers that matter? The mining reward is currently 3600 bitcoins per day in block rewards, plus about 20 bitcoins in transaction fees. That means if miners are rational they will collectively buy about 3620 bitcoins worth of electricity per day.

3620 bitcoins buy a lot of electricity for sure. But it won't always be like this! The block reward halves next year, and transaction volumes will probably increase. _Then_ rational miners will spend perhaps around 1830 bitcoins on electricity per day, while processing more transactions. Wow, we've more than doubled the efficiency in a year!

Furthermore, the block reward keeps halving every couple of years until it goes all the way to 0! At that point, the only thing funding the miners will be transaction fees, so the full costs of running the network will be borne by the users, and market forces will decide the appropriate level of resources to spend on running the Bitcoin network. It could be higher or lower than 215 MW, depending on how useful Bitcoin becomes to users.

<comment><USER5> > the only thing funding the miners will be transaction fees

How does that work, exactly? I thought that the only reward that the miners get is the block reward hard-wired in the system. Is there another mechanism that allows them to negotiate transaction prices with clients and accept/decline transactions?

<comment><USER4> Bitcoin transactions include an optional fee, chosen by the sender, which is paid to the miner who mines the block containing that transaction. Miners choose which transactions go into their blocks. They can accept or decline transactions at will, and also choose which transactions are processed first. Rational miners will process higher fee transactions first, and may also set a fee threshold below which they reject transactions. This mechanism is already in place and working.

Currently transaction fees are negligible compared to the block reward. Many miners are willing to process 0 fee transactions because it hardly costs them anything and promotes use of the network. However this will change over time as the block reward declines and transaction fees become more important.

</comment></comment></comment><comment><USER6> The author of this article has a misconception that the marginal cost for processing a bitcoin transaction is "1.57 American household's yearly consumption". That's not correct -- the marginal cost is closer to the electricity spent by your processor in rendering this web page.

It is the upfront cost of getting a partial SHA256 collision and being able to add transactions to the blockchain that is massive, at least for this level of transactional volume. Bitcoin becomes more sustainable the more people use it, as the average TX costs goes down.

Whether other consensus systems like Proof of Stake should replace Proof of Work is a more interesting question.

<comment><USER7> Proof of state only further incentives hording, generally making it undesirable for economic activity.

</comment></comment><comment><USER8> Another dynamic of bitcoin is that mining is not purely motivated by block rewards; even if there were no rewards at all, people who owned bitcoins would be incentivized to continue mining in order to secure their own currency holdings.

For example, if I had 100BTC and I feared that they would halve in value if the bitcoin network had a successful technological attack, it would be quite reasonable for me to spend up to half the amount of coins I had in mining/securing the network, regardless of other profit... and that arms race also continues even with no money gained from mining due to increasing vested interest.

I think this dynamic is often lost in people estimating what amount of mining a rational actor would undertake.

<comment><USER9> If you owned stock in Pepsi, and their business looked like it was going to go under, would you drive down to the plant and help them bottle the stuff?

The rational response in your scenario would be to sell your BTC and diversify into other assets.

Trying to secure the network yourself suffers from the tragedy of the commons. There is no real incentive besides altruism to not let others bear the cost of doing the work and ride on their coattails.

<comment><USER10> You might not, but if Pepsi produced 90% of the demand for drinking bottles, the bottle makers might. Similarly, bitcoin companies which are not currently miners but which profit from providing bitcoin-related services might have incentive to step in. (Coinbase, Circle, BitPay, etc.)

</comment></comment></comment><comment><USER11> There seems to be a factual error in this: other than what the article claims the number of transactions should not change the amount of energy required.

The Mining network mines a block roughly every 10 minutes, no matter how many transactions there are.

If the amount of transactions rises, the cost in Bitcoin per transaction rises, not the energy required. The cost in Bitcoin rises because you have to give the miners an incentive to actually process the transaction (that is, include it in a mined block). Since the number of transactions per block is limited, there is a bidding competition.

What increases the energy required is only the mining, which depends on the value of Bitcoin. The more valuable Bitcoin is, the more miners will be thrown at it, consuming more energy.

Correct me if I am wrong...

<comment><USER12> There is currently a (ballpark) 7tps limit due to the current 1MB block size limit although this is currently under the subject of intense discussion/debate and will likely be solved in the coming months/years by a combination of increases to the block size (imminent), and the deployments of technologies like side chains and lightning network (both under development).

</comment></comment><comment><USER13> So what is not covered is how this cost of bitcoin compares to the cost of the present central-bank full-fiat system. Take into account the London whale, the libor scandal, forex fixing, comex cartels, all the fees and charges that are skimmed at every stage and flow into the ridiculous levels of Wall Street/The City profits. Take all the criminal actions and the fact that it seems the financial law enforcers are incapable now of bringing financial criminals to justice. How does the bitcoin cost compare to those costs? I don't know, but if I was a gambling man I'd bet that bitcoin is orders of magnitude less expensive. Does anyone have any figures to compare these?

<comment><USER12> Bitcoin will not eliminate most of the market inefficiencies you've listed - certainly not forex, by definition for example. There are already Bitcoin derivatives and other financial instruments being built already.

However, the most comprehensive (and perhaps, relevant) analysis I've seen looks at the costs of printing/minting money and its distribution (banks, ATMs) is here: [http://www.coindesk.com/author/hass- mccook/](http://www.coindesk.com/author/hass-mccook/)

It's from mid-2014 now so the mining article is a bit out of date but there's no reason it couldn't be turned into a spreadsheet to account for current mining efficiency (and modeled against new developments increased block size or lightning network, for example).

</comment></comment><comment><USER14> The central problem that banks solve is the shared-truth problem, and banks solve it by being the score-keepers. Alice's bank owes her $100; Bob's bank owes him $100. If Alice pays Bob $50, Alice's bank owes her $50, and Bob's owes him $150.

That's all there is to it. The key is that the banks have to agree on the truth. A check from Alice to Bob is a statement from her saying "I pay Bob $50", he endorses it, saying, "I accept $50 from Alice" and then the two banks at some point say "1-2-3 go!" and make the change simultaneously.

Until I understand how Bitcoin does that, I will not believe in it. And don't give me hand-wavy bullshit. Speak plainly.

EDIT: Yes, downvote me for wanting to understand, you bitcoin bastards.

<comment><USER15> Is there a reason that you find the existing resources on Bitcoin (the Wikipedia article, the paper, the "how it works" page on bitcoin.org, etc.) unclear? What parts of them do you find un-plain or handwavy? What have you read? Do you concur with the purported answer in part and not in part, or do you disagree completely, or do you not understand it...? Help us help you.

I don't believe that Bitcoin is a _good idea_ , but I certainly believe that it _works_ for the use case / model of the world it has, and I believed it just about as soon as I heard of it, because I found the resources clear. I imagine so have most others, and so us repeating that to you is probably no different from what you've heard already. If you tell us more about what you understand and what you don't, what you've read and what you haven't, then we can give more useful replies.

<comment><USER14> For one thing, if you have a single global ledger, how do you avoid the problem that miners can ignore your transactions if they want to? I have other questions, but none of them matter, really, except this one, because this implies that the score-keepers become bitcoin miners rather than banks, which makes bitcoin a non-solution to the banking problem.

If you transfer money, at what point does the transfer "happen"? If you have to wait for a miner to calculate something during a 10-minute batch of (global) transactions, doesn't this mean that a) everyone has to wait (at least) 10 minutes for a transfer to take place and b) that all global transactions for every 10 minute window have to reach the same place (e.g. the miner)? Do all miners have to agree on the contents of a block before they start mining?

Most discussions of Bitcoin seem to get bogged down in details and jargon. I think the idea is to create a single ledger that monotonically increases in size, with each block of transactions getting integrated with it by solving a (mostly) arbitrary math problem involving the value of those transactions. So I guess my main problem with the system is that it's trivial to alter blocks _before_ integration. The secondary problem is the "waiting for transfer" issue. Or perhaps it's enough for a buyer to hand a seller a signed message saying "I pay you $50" which the seller can a) look at the global ledger to make sure they have the money, and b) integrate into the ledger at their leisure. Which implies there's a double-spending possibility in the window between handing the seller the message and the seller passing the message to the miners for integration.

<comment><USER15> I'm not sure if your question is based on an assumption about double-entry accounting. Bitcoin is _not_ double-entry, at least in the sense that there aren't two separate entries. A transaction transferring $50 from Alice to Bob is a single thing in the global ledger, signed by Alice's key, transferring it to Bob. There's no way to sever "Alice spends $50" from "Bob receives $50", so even if you can cause transactions to be ignored, the whole thing, atomically, gets ignored. The transfer never happened, and no money is created or destroyed.

It is certainly possible for someone to modify a block and try to mine it. There's no required consensus process in advance; you can just try to generate a block that has the data you want, and find a hash that starts with enough zeros. (You can't alter a block so that money is spent without the consent of the money-holder, since each expenditure requires a digital signature. But if, say, Alice's key has signed both "Transfer this bitcoin to Bob" and "Transfer this bitcoin to Carol", you can mine either of those.)

The trouble with trying to do that is that mining is slow. The math problem is timed so that it takes roughly 10 minutes for _someone, somewhere_ to successfully find an answer. So the CPU time is 10 minutes times the number of mining nodes on the Bitcoin network. If you, on your own computer, start trying to mine a block that's different from what everyone else is trying to mine, you are going to have to be extraordinarily lucky to be able to get the math problem solved on your own within 10 minutes. The entire rest of the Bitcoin network is trying to mine a different block, and they'll probably win.

Let's say that you are extraordinarily lucky, or maybe you control like 30% of the network and you're slightly lucky. What you've accomplished is to make a fork in the block chain: there are two blocks with the same parent. You can now send your fork to people, because there's no way to to tell which one was "real" and which one wasn't. But now you need to keep mining on your fork, because people will notice if the block chain mysteriously stops updating. You need to be incorporating everyone else's transactions onto your fork. So not only do you need to be lucky, you need to be _repeatedly_ lucky, all the time, so that your mining keeps up with the other fork. This is only feasible if you actually control 50% of the network.

But still, what have you accomplished? There's no "merge" in Bitcoin. Everyone sees a single history. If they see two blockchains updating at the same speed, they know that something is up and it can be resolved by humans; no program is going to simultaneously trust both histories. So either Alice transferred a bitcoin to Bob (and thus not to Carol), as she authorized, or she transferred a bitcoin to Carol (and therefore not to Bob), as she authorized, or the bitcoin remains with Alice and no transaction happened. The best you can do is prevent people from spending their money, if you reliably control 50% or more of the network. You can't cause money to be double-spent.

And yes, it is common to wait 10 minutes or often 60 minutes to wait out an attacker's luck, at least for large transactions. The official Bitcoin client calls transactions "unconfirmed" until it sees six blocks mined on top, at which point it's assumed infeasible for you to have a separate history from the rest of the network. For smaller transactions, people tend not to wait as long. But the same thing happens with conventional currency. Most stores don't check small bills with counterfeit pens. Most credit card readers support offline transactions, but you get the product immediately. Personal checks can take up to a month to clear or bounce. If there's something high-value, you get a cashier's check or you run a credit report on the person. Otherwise you trade off the risk for convenience.

See the Bitcoin wiki article on confirmation for a bit more discussion about how long to wait vs. how strong an attacker is: [https://en.bitcoin.it/wiki/Confirmation](https://en.bitcoin.it/wiki/Confirmation)

Let me know if I understood you correctly and whether that was answering the question you asked.

<comment><USER14> _> The best you can do is prevent people from spending their money_

And that's pretty damn good, because if you want to do the most damage to someone, you cut them off from their money.

So, most of the time these threads are abandoned, but I really do appreciate your thoughtful responses, and I'd like to continue, because I think I'm finally able to articulate my concern clearly: the trouble is that there is a distinct, separate group of miners who can form out-of-band cabals and cooperate to effectively cut anyone they want off from their money. All it would take would be for a majority of them to agree to ignore transfers from a public key, and the ledger would continue along just fine.

So, the root of banking power is currently institutional and legal, and all bitcoin is doing is giving that control to people with the most compute power. Bitcoin turns CPUs into the new gold standard (although ASICs function more like tulips).

On a related note, I'd like to understand on a practical level how people reach "the miners" and whether or not the miners have incentive to share transactions with each other once they learn of one, or whether the system relies on a "neutral" third party clearing house for unintegrated transactions. Presumably there are lots of endpoints in the world where you can put transactions, but what guarantee do you have that anyone will bother integrating yours? Do you push it to lots of endpoints to reduce the chance that happens (intentionally or by accident)? Or, another way to ask this, is: how do miners learn of unintegrated transactions?

<comment><USER15> > And that's pretty damn good, because if you want to do the most damage to > someone, you cut them off from their money.

Hmmmm. So, in order for someone to spend money, they just need _one_ transaction in the blockchain moving the money to someone else. In order to cut them off, you need to make sure that transaction _never_ gets mined.

Since there are lots of miners, even if you control part of the network, someone in the rest of the network could mine the transaction. Then you're in the position of having to refuse that block and maintain a fork. That's probably tenable if you control like 95% of the mining power. I'm not convinced that's tenable if you control even 50% of the mining power. If your victim keeps trying to transfer their money, you'll fairly often find the other 50% of the network having a block that you refuse to accept, and (I think) you won't be able to get your fork to reliably win automatically. IF you keep refusing blocks, it'll involve human intervention on the other 50% of nodes to consider your history the "real" history, and people will notice that something strange is happening.

You could, of course, accept the transaction, track their coin, and consider all money from its recipient tainted. But there are enough large wallets, like large exchanges and even tumblers (essentially money-launderers) that obfuscate the relationship between inputs and outputs. You're going to have to start blacklisting a _lot_ of money if you want that approach to work.

> So, the root of banking power is currently institutional and legal, and all > bitcoin is doing is giving that control to people with the most compute > power.

Yes, this is basically my biggest personal disbelief about Bitcoin: many governments could out-mine the entire Bitcoin network right now if they decided that it was important to national security. I'm not convinced this is a fundamentally unsolvable problem (there are some alternative models, Stellar's consensus protocol probably being the most interesting) so I'm not a cryptocurrency skeptic, but I am a Bitcoin / proof-of-work skeptic. There do seem to be a bunch of people in the Bitcoin community interested in alternatives to proof-of-work, which I think is healthy.

(And relatedly, if we _don 't_ need proof-of-work for security, either because something else works or nothing possibly works, let's stop building a world in which we have to burn energy for currency transfer.)

> On a related note, I'd like to understand on a practical level how people > reach "the miners" ... how do miners learn of unintegrated transactions?

I don't understand this clearly and I'm currently the wrong person to ask. The best I can find is [https://en.bitcoin.it/wiki/Transaction_broadcasting](https://en.bitcoin.it/wiki/Transaction_broadcasting) plus [https://en.bitcoin.it/wiki/Network](https://en.bitcoin.it/wiki/Network) (there's some IRC-style way of learning about nodes, and I think at the network level, ~everyone is a node and considered capable of mining). I suppose the paper might know more; we could look.

<comment><USER14> _> I don't understand this clearly_

I would consider understanding this to be a necessary condition for advocating for (or using) BitCoin.

Also, one of the interesting outgrowths of focusing on the reachability of the network is that a few features of the network. Assuming the network is accepting all transactions, miners _must_ be working on different subsets of transactions routinely. This implies that there's quite a lot of computation getting thrown out, routinely, as different miners start working on different subsets of transactions.

It also implies that there is a miner-to-miner DOS method, where the majority of the miner network blackballs a miner - no longer accepts their integrations. This is serious, but much less serious than an arbitrary public key freeze, which can affect anyone (your tumblers aside, it's always possible).

Finally, I begin to understand why Satoshi started with money. I suspect at some level this is not about money, but he needed to incent people to get this ball rolling. What is it about? It's about coherent, persistent truth. Transactions are just one kind of event that happens in the world. The pattern is valid for any global data-structure that you want to have great survivability and coherence. You might use something like the blockchain (adding back a _little_ jargon) to store, for example, the mind state of an AI. The proof of work, rather than a mechanistic search for arbitrary hashes, might be somehow related to the operation of the AI's "mind".

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Correct me if I'm wrong, but the idea of the blockchain is that everything is recorded in it right?

So there is more and more information stored in there, redundantly. So eventually it'll take way too much space for everyone?

(And the more adoption there is, the faster this process is)

<comment><USER17> Yes, that's one of main argument raised against increasing transactions per block - it would increase block size and ledger growth rate.

<comment><USER10> Increasing the block size doesn't increase the transactions per block. Usage does.

</comment></comment></comment><comment><USER9> This is why I hope that Proof of Stake currencies currencies like Neucoin take off.

<comment><USER18> Exactly. Many like to focus on the shortcomings of Bitcoin (of which there are many, I agree). Some more even like to predict the 'death of Bitcoin' based on these. However we shouldn't ignore the fact that cryptocurrency is developing rapidly (hell, it's only 6 years old), and many obvious issues are being slowly but surely worked on (privacy, wallet security, energy consumption, mining decentralisation, sustainability and tx fees, microtransactions, contracts, scripting, etc.).

As for when it hits mainstream consumer adoption, who knows. I'm here for the ride.

</comment></comment><comment><USER19> Someone I know covered his roof in solar panels. Instead of buying a big battery, he just runs a BC server farm. It's not unsustainable.

<comment><USER20> That only works if it becomes part of the BTC protocol that you can only mine if the electricity comes from renewable, non-polluting sources. Otherwise, due to solar not being the cheapest, most accessible source of energy everywhere that people want to mine BTC, you'd have lots of people choosing to increase greenhouse gas emissions in order to fill their own pockets.

It would be interesting to see estimates of the cost of those greenhouse gasses, in terms of extinct species, effort to clean up the atmosphere, or other expensive/bad things that can happen when you claim that increasingly using energy in non-efficient ways is just fine. Are these costs higher or lower than the value of the money created?

Perhaps BTC is sustainable, but your argument certainly does not refute the article's claim - at least, until we've already solved our energy & pollution problems.

<comment><USER19> If bitcoin does become even more mainstream, given its energy requirements and the potential strain it may put on existing traditional infrastructures; will solar and other alternative power sources always be more expensive?

<comment><USER21> There's no economy of scale for solar - just more and more panels, in contrast to more traditional power sources where running one big boiler / set of turbines can be more efficient. So I think solar gets worse off as electricity demand increases.

<comment><USER22> There's an economy of scale in producing solar panels. And there can be economies of scale in installing them.

</comment></comment></comment></comment></comment><comment><USER23> There is no question mark in the original title, though probably there should be one.

It's only one character, but adding it has significantly changed the meaning of the title. The article is full of confident statements of opinion, presented as facts, so I don't think the writer intended to make that title into a question and invoke Betteridge's Law of Headlines.

Whether it's correct or not, it does seem like the issues raised in this article have been discussed many times before during the past 5 years. Is there anything really new?

Here's some reaction to it from the pro-bitcoin side: [http://redd.it/3bj0vo](http://redd.it/3bj0vo)</comment>


Antarctic Journal: Life on the ice - <AUTHOR> http://www.nature.com/news/icediary-1.18738 <comment><AUTHOR> There will be a live chat on November 20th

        if you've got questions, I'll be online to answer them on Friday, 20
        November, at 9 a.m. US Eastern time (3 a.m. Saturday in McMurdo); you
        can pre-register for the chat.

Chat (November 20): [http://www.nature.com/news/live-chat-life-on-the- ice-1.18796](http://www.nature.com/news/live-chat-life-on-the-ice-1.18796)

Twitter: [http://www.twitter.com/sioglaciology](http://www.twitter.com/sioglaciology)

Instagram: [http://www.instagram.com/sioglaciology](http://www.instagram.com/sioglaciology)

Facebook: [http://www.facebook.com/sioglaciology](http://www.facebook.com/sioglaciology)</comment>


"Are empty interfaces code smell?" - <AUTHOR> https://medium.com/@ssg/are-interfaces-code-smell-bd19abc266d3#.iebq4fmw7 <comment><USER2> I would suggest the author move anything they want to keep available to a publishing platform they own. There is nothing to say that Medium will be there forever.

Regards to the subject, I think there are times when empty interfaces are acceptable. NServiceBus I seem to recall uses them as decorators to determine startup objects. Also seen this used with looks like Ninject. I think it's a valid use of the interface construct.</comment>


Show HN: Review Mailer, track your iOS App Store reviews - <AUTHOR> http://www.reviewmailer.com/

<comment><USER2> I don't get it, doesn't apple email you reviews?

<comment><AUTHOR> No, you need to check either log into your iTunes Connect account and manually check the reviews for each country.

Review Mailer does all the leg work for you and also translates the reviews into English (more languages will be added if there is demand).

</comment></comment><comment><USER3> Nice job guys. I will check it out</comment>


Pandas 0.15 has been released - <AUTHOR> http://pandas.pydata.org/pandas-docs/stable/whatsnew.htmlhttp://pandas.pydata.org/pandas-docs/stable/whatsnew.html#v0-15-0-october-18-2014

<comment><USER2> I work in pandas 95% of my day doing data automation tasks, manipulating sql queries, and data-munging for machine learning. It is literally life changing for someone like me.

I used to program solely in R, but after discovering pandas I really have no need to go back to R. My project workflow consists of several IPython notebooks+pandas+sklearn.

Works extremely well in production, as in, on a flask web server, as well.

<comment><USER3> You ought to take a look at [https://pypi.python.org/pypi/ipython- sql](https://pypi.python.org/pypi/ipython-sql). This, in conjunction with IPython magic helpers specified in your IPython profile, can turn IPython into a SQL client. Here's a good example: [https://gist.github.com/slnovak/583e35083ebd42892fab](https://gist.github.com/slnovak/583e35083ebd42892fab)

<comment><USER4> Thanks for this, looks like it's going to be pretty handy.

</comment></comment></comment><comment><USER5> No discussion of the new features?

Categorical is awesome, and equivalent to R's c() iirc. This should make plots easier in terms of automatically deciding whether to facet something, or showing legends nicely etc.

The memory usage feature is super neat.

Also for those of us stuck with STATA, the to_stata() and read_stata() just got much better.

I'm eagerly awaiting a numpy native NA value instead of np.NaN.

</comment><comment><USER6> I have some experience using Pandas but I'd love to read about peoples experience using it in production or in large teams. Please share!

<comment><USER7> It seems quite quick to do work on large datasets, I've found the documentation lacking however.

There are no links in docs to the types that are being referenced, some types do not have documentation, some documentation is the function header with no other info ie no documentation, functions that take string formatting info eg '5min' do not have their argument possibilities documented anywhere I can find.

<comment><USER8> Really? You found the documentation to be lacking.

FWIW, there are over 1500 pages in the docs including a short-over view, tutorials, extensive feature coverage, and interaction with other tools: [http://pandas.pydata.org/pandas- docs/version/0.15.0/pandas.p...](http://pandas.pydata.org/pandas- docs/version/0.15.0/pandas.pdf)

The docs may have some issues, but they certainly can't be characterized as lacking.

<comment><USER6> In my eyes, you both make a valid point: yes there's plenty of documentation but sometimes I just can't find what I'm looking for. I like how the book[1] is structured, it really helped me but it isn't complete.

Don't get me wrong, I'm grateful for all the work and I know I haven't contributed much but I think the online could be improved with more examples and recipes.

Edit: There really is no excuse, getting started is easy[2].

[1]: [http://shop.oreilly.com/product/0636920023784.do](http://shop.oreilly.com/product/0636920023784.do)

[2]: [http://pandas.pydata.org/developers.html](http://pandas.pydata.org/developers.html)

<comment><USER9> Correct me if I'm wrong but perhaps you had the same issue as me. The documentation is plentiful, lots of good examples and the book, similarly, increases with a nice linear complexity from basic "how do I select a (cell | row | column) ..." to full blown how do I do timeseries analysis on a dataseries pulled in from a remote source.

The issue I had was not the documentation but the language of pandas mirrors the language used in R (I think this is something Wes McKinney intentional did) and it's the burden of all that new verbage that makes the documentation harder to sift through. Some choice exampels; "melt", "stack/unstack" and "reindex" — necessary, I grant you, so that functions can be aptly named and in turn encapsulate vectorised procedures that are composable.

I found that the documentation was harder to search because I lacked the domain language and the documentation, for better for worse, doesn't dawdle with educating the reader about the verbage — worked examples often provide a easier route. It reads like a mathematical proof rather than prose and I used to think that the documentation was too terse but now I appreciate that probably just succinct.

</comment></comment></comment></comment></comment><comment><USER10> Change log: [http://pandas.pydata.org/pandas- docs/version/0.15.0/whatsnew...](http://pandas.pydata.org/pandas- docs/version/0.15.0/whatsnew.html)

In particular, note that NumPy 1.7.0 or newer is required.</comment>


How and Why Google+ Failed and Its Future - <AUTHOR> http://wphold.com/how-and-why-google-failed-and-its-future/ <comment><USER2> Perhaps Google never really understood _social_. The _#NymWars_ along with so many privacy statements from the top indicated that Google management was simply out of touch with the realities of how to build a social community. Features only go so far - and Google proved that.

</comment><comment><USER3> anybody else get "Account suspended?"</comment>


The 1999 and 2003 messages explained [pdf] - <AUTHOR> https://www.plover.com/misc/Dumas-Dutil/messages.pdf <comment><USER2> I wrote a long series of blog posts about every aspect of the messages. They are among the blog posts I'm most proud of. I think there are 25 in all, one for each of the 23 pages, and a couple of extras about the message as a whole.

The first post, and table of contents: [https://blog.plover.com/aliens/dd/intro.html](https://blog.plover.com/aliens/dd/intro.html)

(I also produced good-quality, bit-for-bit bitmaps of the 23 pages; I don't think anything like this was available before. (At least, I couldn't find any.) [https://pic.blog.plover.com/aliens/dd/](https://pic.blog.plover.com/aliens/dd/) )

</comment><comment><USER3> [https://www.wikipedia.org/wiki/Cosmic_Call](https://www.wikipedia.org/wiki/Cosmic_Call)

[https://www.smithsonianmag.com/science-nature/how-couple- guy...](https://www.smithsonianmag.com/science-nature/how-couple-guys-built- most-ambitious-alien-outreach-project-ever-180960473/)

</comment><comment><USER4> The paper about the messages written by Dumas and Dutil:

[https://www.researchgate.net/publication/228862784_The_Evpat...](https://www.researchgate.net/publication/228862784_The_Evpatoria_Messages)

As I was young, I watched Star Trek and listened to Carl Sagan's positive expectations about the "first contact." But that was before the modern Internet.

Now I'm much more pessimistic. I'm almost sure that the biggest chance of anything outside of Earth responding would not be something we'd like:

I would expect either cosmic spam, cosmic scammers or cosmic criminals to respond. And it can be even worse, to the point of some powers that do some planned destruction out of pure indifference to what the effects are, like Douglas Adams writes: just "to make room for a hyperspatial express route" and even if the Earth was not exactly there it was close enough that the "cleaning" from "risky" lifeforms will be performed and your time to file a complaint expired, thank you very much, we really care about your opinion, to return to main menu press 0.

So I'm thinking more like Hawking:

"Meeting an advanced civilization could be like Native Americans encountering Columbus. That didn't turn out so well." (1) ... (to Native Americans).

Some quite recent news, probably influencing me: [https://www.sciencealert.com/a-46-000-year-old-aboriginal- si...](https://www.sciencealert.com/a-46-000-year-old-aboriginal-site-was- just-deliberately-destroyed-in-australia)

1) [https://www.nationalgeographic.com/news/2018/03/stephen- hawk...](https://www.nationalgeographic.com/news/2018/03/stephen-hawking- controversial-physics-black-holes-bets-science/)

<comment><USER5> An alien species would certainly be incompatible with our germs, possibly incompatible with the basic life-chemisty of our planet, and would likely be far enough away that we're restricted to swapping a message like once a generation assuming we're anywhere near right about the basic laws of physics. I wouldn't worry too much about it. The worst case is they will troll us.

<comment><USER6> Oh, good. Trolling. That's never been a serious problem before.

</comment></comment></comment><comment><USER7> there went our dark forest. :)

<comment><USER8> I was about to make the same comment:)

Take in mind that we emit so much garbage into space that it would probably make no difference for sufficiently advanced civilization.

So if there really exist a civilization that goes out and kills everybody and only other civilizations survive because they maintain absolute silence, it must be already extremely advanced (to be feared by everybody else) and so we have already lost.

<comment><USER4> The claim that: "we emit so much garbage into space that it would probably make no difference for sufficiently advanced civilization" is a technologically wrong claim. Under some emitting power to some specific destination, the kind of emissions we commonly make drop to the levels which are below all the noise levels, effectively making them unrecognizable. Under the noise levels, it simply can't be resolved.

The only way for our common emissions to be recognized would be if the "other civilization" already has some receivers in our solar system or very close to it. But if we assume that we have to send something in the direction to some distant star to get their attention, then it can be better not being "too loud."

For the start, even on Earth you have to have a license to use some bandwidth, and some are completely forbidden for mortals. And again, imagine some indifferent Vogon bureaucrats deciding what to do with the annoyance...

<comment><USER8> You are looking from the point of view of our very limited technological level.

To understand the problem you need to look at physical limitations of a civilization. A civilization that has an ability to wipe off another civilisation in another remote star system will definitely be at least hitting some physical limitations if not pushing them (if our understanding of physics is wrong).

We already have plans to image other planets by use of gravitational lensing with something like 25km per pixel resolution.

If we can image planet surface with this resolution remember, radio signals are also being amplified by gravitational lensing. While it seems it is more complicated I don't see any technical limitation to receiving even very weak radio signals this way.

I mean, if we can almost do it now it is naive to think they can't do it.

Our current biggest to getting this level of image is putting drones in right, remote place in space many AUs from us. If we are talking about a civilisation that has means and time to wipe off other star system then they definitely don't have that problem.

<comment><USER4> > If we are talking about a civilisation that has means and time to wipe off > other star system then they definitely don't have that problem.

No, I'm not talking about a civilization that would "wipe" the star system. I'm not talking about a civilization that uses instruments bigger than the solar system only to detect us. I'm also not talking about a civilization that would be faster than light. I'm just talking about a civilization that has some very strict (imagine, like the extremists in our world, but a few orders of magnitude more) views about what they "have" to do, and that has the attention span and endurance more orders of magnitude longer than ours, meaning that they wouldn't mind to send something to the Earth even if it would take, for example, 1000 years, and then make more steps to their benefit, etc.

In short, our thinking of what is "far" and "reasonable" are limited by our very short lives. I of course don't think that I should worry in my lifetime about the possible responses, but I don't think that the humanity in thousands of years should be put in danger by our "young and naïve" actions now.

The dangers I see are certainly not in the magnitude of "wiping off the star system", but more like those described by Rod Serling as "to serve man."

[https://en.wikipedia.org/wiki/To_Serve_Man_(The_Twilight_Zon...](https://en.wikipedia.org/wiki/To_Serve_Man_\(The_Twilight_Zone\))

Even the current humans are certainly technologically capable to destroy our civilization as we now know it, even if there's a possibility that a few specimens of humans would survive for a while somewhere. The aliens don't have to be much more capable than that.

<comment><USER8> Have you actually read The Dark Forest? Because that scenario is what I was commenting about.

The scenario says that the only logical conclusion is that, since resources are limited, if you are left with another civilization the most logical course of action is to preemptively, immediately strike and destroy it so that you can gain their resources and are in better position for the future encounters.

For that reason all civilizations keep total silence for fear of another civilization wiping them off.

<comment><USER7> I didn't understand the dark forest about gaining their resources in the context of the novel, (even though that's mentioned, I'll discuss below). I believe the stronger argument is about the inability to trust them at such great distances and time deltas (i.e. you can't trust, but verify).

to recap: even if they meant what they said at t0, by the time you get the message at time t(1billion) (just picked a large number), their thoughts could have easily changed due to their development in the time that has elapsed.

therefore, if you have the ability, the only "logical" thing is to wipe them out. Of course, this presumes the ability to wipe them out with one shot (2d foil), not get into a shooting war even if you are technologically superior (i.e. trisolarans)

with that said, where I felt the logic of the novel fell apart a bit was in the context of the sophons. i.e. the technology for instantaneous communication existed (or at least was built). which negates one of the axioms.

now to get back to the resource scarcity argument, while resource scarcity is mentioned, I also think it as basis is problematic. why? because a common method used to destroy these far off civilizations is effectively resource destruction (ex: collapsing 3d space into 2d space). If your goal is to maximize your resources (as opposed to minimizing your opponents resources), you don't go about "destroying" them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Well now I'm curious: what are the "questions" posed in frame 23?

<comment><USER2> [https://blog.plover.com/aliens/dd/p23.html](https://blog.plover.com/aliens/dd/p23.html)

<comment><USER9> Thanks! That's helpful, but like you say it's also confusing.

</comment></comment></comment><comment><USER10> Happy to see it uses my favorite map projection.

Relevant XKCD: [https://xkcd.com/977/](https://xkcd.com/977/)

</comment><comment><USER11> Does anyone know why MJD posted this? (Well, probably MJD does. So I guess I mean: Is anyone here in a position to explain why MJD posted it? Just general interest to them?)

<comment><USER2> I posted this because around 2003 I spent a significant amount of time tracking it down. So I saved it, so that I wouldn't lose it, and so if I ever got around to writing an article about the message, I would have it handy and easy to find. This is important, because when I finally got around to writing the articles, twelve years later, I found it where I had left it.

When I save something that I had trouble finding, I often try to save it in a place that other people will be able to find it, so save trouble for the next person. I don't remember where I found the paper the first time around, and I don't know if that location still exists. But stuff I throw into plover.com/~mjd/misc is (so far) available forever. There are files there that haven't been modified since 1994.

<comment><USER11> Thank you!</comment></comment></comment>


Quantum Weirdness Once Again Shows We're Not Living in a Computer Simulation - <AUTHOR> https://www.sciencealert.com/quantum-complexity-rules-out-our-universe-as-a-computer-simulation <comment><USER2> I am amazed that this has not gotten more attention here, given the amount of attention a story gets when <insert your favorite famous tech mogul here> says we might be living in a simulation. We are not. This also argues against simulations of the human brain, or possibly, most biological systems, including even individual proteins. The complexity is simply far greater than anyone can even begin to comprehend. Anyone who wrangles with real scientific data learns this very quickly. The number of very intelligent people led astray by this should serve as a caution to us all to dial down the near- religious fervor with which we greet almost all of their pronouncements.

<comment><AUTHOR> _Amen Brother_</comment></comment>


Ask HN: How to choose a business/brand name? - <AUTHOR> <comment><USER2> If you plan to sell the business/brand in the future then you would be advised to avoid anything that relates to your name. On the other hand if your expertise, profile, etc are relevant and you do not intend to sell in the future then using your name might be of value.

The hardest part is to come up with a name that is available under your state's/country's business /company names register, is available for domain name registration and does not violate any pre-existing trademarks. Trademarks are particularly tricky because there are international treaties that can lead to an overseas trademark being infringed even if you can register in your own country.

</comment><comment><USER3> Igor Naming Agency has a very good guide[1] and online reference[2].

There's also SquadHelp[3] for running a naming contest.

[1] PDF - [https://www.igorinternational.com/process/igor-naming- guide_...](https://www.igorinternational.com/process/igor-naming-guide_12.pdf)

[2] [https://www.igorinternational.com/process/company-product- na...](https://www.igorinternational.com/process/company-product-names.php)

[3] [https://www.squadhelp.com](https://www.squadhelp.com)</comment>


14 Best-Selling Books Repeatedly Rejected by Publishers - <AUTHOR> http://entertainment.howstuffworks.com/14-best-selling-books-repeatedly-rejected-by-publishers.htm

<comment><USER2> To save you the annoyance of having to click through to a new page for every single title:

       1. Auntie Mame by Patrick Dennis
       2. Jonathan Livingston Seagull by Richard Bach
       3. Chicken Soup for the Soul by Jack Canfield and Mark Victor Hansen
       4. Kon-Tiki by Thor Heyerdahl
       5. The Peter Principle by Laurence Peter
       6. Dubliners by James Joyce
       7. Lorna Doone by Richard Doddridge Blackmore
       8. Zen and the Art of Motorcycle Maintenance by Robert Pirsig
       9. M*A*S*H by Richard Hooker
      10. Carrie by Stephen King
      11. Gone With the Wind by Margaret Mitchell
      12. A Wrinkle in Time by Madeleine L'Engle
      13. Heaven Knows, Mr. Allison by Charles Shaw
      14. Dune by Frank Herbert

And direct links if you want to read more about an individual title:

1\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers1.htm)

2\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers2.htm)

3\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers3.htm)

4\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers4.htm)

5\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers5.htm)

6\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers6.htm)

7\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers7.htm)

8\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers8.htm)

9\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers9.htm)

10\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers10.htm)

11\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers11.htm)

12\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers12.htm)

13\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers13.htm)

14\. [http://entertainment.howstuffworks.com/14-best-selling- books...](http://entertainment.howstuffworks.com/14-best-selling-books- repeatedly-rejected-by-publishers14.htm)

<comment><USER3> I rejected Dune. Sorry. I thought, "Sand! Who wants to read about a big ball of sand? With worms? Ew!"

My bad. You can downvote me down. I have a little karma to burn. Going to bed now.</comment></comment>


Alternative Evernote Client for Mac OS X - <AUTHOR> Hey guys!
We're developing an alternative Evernote client for Mac. That's why I wanted to know which features you would like to see in an ideal note-taking app? What's bothering you most in Evernote?
We're launching really soon, so subscribe to our private beta at http://alternoteapp.com <comment><USER2> Looks very nice. You got my attention what what looks like a much better writing experience. I also noticed you guys are from Ukraine. I'm not very informed about the current conflict there, but props for shipping your product during such a time. I look forward to using Alternote.

</comment><comment><USER3> Honestly, a feature for distraction free note-taking / writing would be nice with better formatting support than the standard app. I always think evernote would be a great idea for writing rough drafts of memos or articles but I very quickly realize that its text formatting is crap. Seriously, it is aggravating to write anything more complicated than a grocery list. Don't get me wrong, its great for importing and searching PDFs and especially scanned documents, but its really bad for writing. I'm not sure what the focus of your client is, but if you fixed this, I would very quickly become an adopter.

<comment><AUTHOR> Thanks for your feedback. You got us right, we're focusing on comfortable writing and we want to make Alternote the best fit from writer's attitude.

And of course you will make use of all Evernote advantages like lots of snippets and extensions which will sync all your notes back to Alternote.

</comment></comment><comment><USER4> Code formatting & syntax highlighting (like in [https://gist.github.com/](https://gist.github.com/) ) are the only missing features for me.

<comment><USER5> Agreed. Evernote has a beta version you can try, and it's still missing this feature.

[http://blog.evernote.com/blog/2014/06/23/evernote- mac-5-6-be...](http://blog.evernote.com/blog/2014/06/23/evernote- mac-5-6-beta-1-available/)

</comment></comment><comment><USER6> Looks like it'd be much more pleasant to write longer notes in your app, so that's great!

One thing I really dislike about Evernote is the crazy behavior you get after you paste in formatted content.

Personally I would like some kind of markdown support.

</comment><comment><USER7> I don't use Evernote much anymore so maybe this is already possible, but it would be cool to see all of my todo lists in all of my notes in one place (maybe with the note name as the heading for each list).

<comment><USER8> Great idea! We will consider this for further versions of Alternote.

For now you can tag every to-do note and quickly access a list of them.

</comment></comment><comment><USER9> Pretty good. Not really connected, but have you guys tried Nevernote ([http://nevernote.sourceforge.net/](http://nevernote.sourceforge.net/))?

</comment><comment><USER10> Solid, absolutely solid syncing.

I've seen many syncing/note-taking apps which failed to do this. I could expound on this, but really, that's all I want: rock-solid syncing.

</comment><comment><USER11> Screenshots or a way to easily paste them. Being able to quickly sketch a few rough things on an image. Just lines, text, arrows, boxes, circles, etc. would be fine.

</comment><comment><USER12> A small addition would be the strikethrough (line through). Also, the default Mac colorpicker bothers me in Evernote. Would be nice to do something about that, too.

</comment><comment><USER13> Markdown or Common Mark writing support.

</comment><comment><USER14> Robust Applescript support please

</comment><comment><USER15> Markdown support!

</comment><comment><USER16> Looks great! Are you going to have reminders support?

<comment><AUTHOR> Thanks! Not in the first version, but we're going to have full Evernote api support further, including shared notebooks & reminders.</comment></comment>