Electron considered harmful - <AUTHOR> https://drewdevault.com/2016/11/24/Electron-considered-harmful.html <comment><USER2> This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside.

But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism.

The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept.

An Electron-wrapped SPA is safer than going to the same website in a multi- tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management.

For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.

<comment><USER3> > It's 2016, people, the ship has sailed on pretending JS isn't a real > programming language. Phrasing the argument the way he does just betrays his > smug elitism.

Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people here seem to enjoy node.js).

> The fact is, for many types of applications, Electron is a really good fit: > for example, _shipping a single-page webapp as a desktop app_ , a need that > surfaces often in today's world, despite his derision of this concept.

I feel it's unreasonable to turn a single web page into a desktop app by bundling an entire web browser with it.

> ...because they can treat it like any other desktop application -- with > hardware access, and subject to the OS' native task management.

If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?

> For other apps, Electron allows the world's most popular layout system > (HTML+CSS) to be used with one of the world's most popular programming > languages. This is a huge boon for re-using knowledge, and perhaps does lead > to some amateurish projects. Similar criticisms were leveled towards Visual > Basic, where drag-and-drop composing and a good IDE enabled people to > quickly crank out a GUI app from an idea.

HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.

The resource bloat and (usually) extreme disparity with the native user interface rarely makes it worthwhile for me to use an electron app. It feels like forcing a square peg into a round hole because the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone. Yes, there are well-made electron apps (like VS Code mentioned in the article), but I, personally, would hate for it to become the norm.

<comment><USER4> _JS is a terrible programming language_

I can never see the point of comments like these. Not one person who reads that will have his mind changed.

 _HTML /CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer._

No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.

<comment><USER3> > I can never see the point of comments like these. Not one person who reads > that will have his mind changed.

I wasn't expecting to change anyone's mind with that. There are more robust programming languages that don't have the same inconsistencies and idiosyncrasies and encourages better practices in general (even though it is true than you can write terrible code in any language).

> No it doesn't. Either the developer benefits or doesn't benefit from > "refusing". There's only so much time in the day. I'll refuse to to learn Qt > or gtk+, unless there is some overwhelming benefit for me to learn it.

That is true, but consider that the end product is not necessarily meant to be most convenient for the developer. Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives. I have read in the past that Electron also posed some difficulties for screen readers, for example (although I'm not sure if that is still the case), which might not be something that impacts you as the developer, but which can make it harder for someone to make use of your software.

<comment><USER5> This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.)

You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day.

Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.

</comment></comment></comment></comment></comment><comment><USER6> I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself.

Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do.

In the end, for most companies, it's more about shipping product that sells than spending 5x more time writing it in C# because "you're an engineer so you should act like an engineer." That's not how the world works. And until you figure that out, you'll constantly be left behind by others who made compromises to capitalize on the market.

Early optimization is the root of all evil.

<comment><USER7> > I'd be willing to bet my net worth your users don't care at all how you > built it, just that it does what they want it to do.

That's exactly right, except "what I want it to do" is not use up all my RAM.

<comment><USER6> Yeah...I could do without the RAM munchers.

</comment></comment></comment><comment><USER8> _sigh_

First off, JS is a perfectly usable language. In some respects, it's even great: of the "big three" scripting languages (Python/Ruby/JS), it's the only one that got Lambdas right, and also got closures right (unlike, say, Python). It has sometimes-quirky syntax, and some odd semantics, but they don't bite as often as you'd think.

Second off, I would say that this article is right about the bulk of Electron: It's a pretty massive thing to lug around with your app, and not ideal in any sense. However, if you want to build a UI very fast, there is _nothing_ better than HTML/CSS for it. Except maybe TK.

Speaking of TK, I would actually advocate TK over Electron: it's easy to use, has bindings to pretty much every language out there, and with TTK, it doesn't look like crap.

Finally, "considered harmful" essays rarely do any good, and frequently do harm.

So yes, while I usually like Drew's writing (at least a little: he's good, but far from the best), I wish he had spent the time he spent writing this doing more work on SCAS.

Seriously. If SCAS was actually done, and documented, and usable, that would be great. There is a freaking vacuum of good assemblers for the platform: another one would be nice.

<comment><USER9> Hello again, qwerty'. Thanks for stepping up on the JS issue :-)

There are many good languages out there, "when used as directed". Alas, out here in the flyover country of Sacramento, there is really only demand for 3 kinds of jobs: Java, C#.NET (falling off), and some Javascript, ignoring the long tail of one-of-a-kind shops. Given those choices, I'll take the Javascript. Java 8 lambdas are clumsy to use to assemble much in the way of higher order functions.

I mean, cuz, who doesn't want to put _this_ as a parameter into a function/method header:

(..., BiFunction<Map<String,Object>,Map<String,Object>,Map<String,Object>>, ...)

E.g. - for the sake of argument, say I needed a callback to merge two associative arrays. Oh, you needed a third input argument? Write your own interface type, so you can use it to declare the callback parameter.

No, I'll take the JS, thank you very much.

(as we discussed a month or two ago, Java is a [somewhat] new Business Oriented Language, and it's pretty Common)

<comment><USER10> I couldn't agree more with this. Just the fact that functions are a first class type in JS already makes it better than many other languages.

Another thing that JS is great at is the flexibility it provides: objects are very general and you can do almost anything with them.

Anyone would care to explain why does JS take so much hate?

<comment><USER11> [http://softwareengineering.stackexchange.com/questions/22161...](http://softwareengineering.stackexchange.com/questions/221615/why- do-dynamic-languages-make-it-more-difficult-to-maintain-large-codebases)

The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example.

Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almost always quite smart and very practical. They don't care if first class functions are sexy. They just want to write high quality code quickly. If they've spent so much time wrapping it up, you know it's because they had serious issues being productive at scale with js. They, and people on their team, probably got extremely frustrated along the way. Hence the hate.

<comment><USER8> Sooo... people don't like JS because 1) it's dynamically typed, and 2) they don't like JS?

>They don't care if first class functions are sexy.

It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.

<comment><USER11> Sorry but this reply is just kind of vacuous given the link I posted. Eric Lippert gives a pretty detailed, neutral, blow by blow summary of the issues working with js at scale. And he quite specifically says that dynamic typing is not intrinsically the problem, just that dynamic typing tends to be correlated with other things that are a problem. He specifically mentions things like error handling. Did you even read the link?

I think your attitude is more that nothing is really bad with js relative to other languages, more so than actually trying to understand why it draws a lot of criticism, which is what you claimed and what I tried to link to.

<comment><USER9> I read it. It assumes mutable OOP. Yes, "those people" need a safe place to play so they don't hurt themselves :-)

(I'm ignoring the error handling thing, as I have not done enough server side JS to have a good feel for how the Node API handles things like I/O failures)

IDEs are starting to have better support for Javascript (or similar dynamic/functional languages). In the near future, the IDEs should effectively have type inference. Once you relegate (mutable) OOP to a tool of last resort, and embrace immutable value objects plus (higher order) functions as your primary methodology, you get the automated error checking _and_ much less drivel to read through during maintenance.

OTOH, I suppose this means the dynamic/FP languages will remain a productivity lever for motivated "experts" only, sadly. At least until there is enough butt-kicking in the market that Java (and its ilk) will be displaced as was COBOL before it. COBOL was "safe" and fast, but we finally reached a tipping point were it was too painfully obvious that it simply wasted too much time writing and reading it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I recently had to decide on a GUI technology for a file manager I'm developing [1]. Electron is sexy, but unfortunately takes way too long to start for my purposes. I ended up with PyQt:

Pros:

\+ Fast startup speed

\+ I can use Python (and its vast ecosystem)

\+ Qt has good ready-made components for eg. displaying a list of files (which is exactly what I need)

Cons:

\- Compiling Qt (which I have to do for various reasons) takes time and is a pain

\- Bundling and deploying a Qt-based app (times 3 - OS X, Windows, Linux) is a pain

\- I have to deal with auto-updating myself (which I believe Electron supports out of the box) - times 3.

\- I would prefer to lay out the UI in well-understood HTML/CSS. Qt's components and its CSS-equivalent behave in very weird ways sometimes.

I still sometimes wish I could use Electron but as OP says, we're supposed to pick the right tools.

I explain my reasoning for picking PyQt over Electron (and other alternatives) in a blog post [2].

1: [https://fman.io](https://fman.io)

2: [https://fman.io/blog/picking-technologies-for-a-desktop- app-...](https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/)

<comment><USER5> A file manager would not be a good use-case for Electron. Especially if you don't intend to run it in the browser (which really would make no sense.)

For the very reason you outlined - startup times. The average use-cases of file managers are being opened and closed very often. Electron is rather aimed at long-running applications you don't usually restart, like Atom and VSCode.

Microsoft could've ported VS to other platforms, yet they chose Electron. I'm sure they spend quite a while analyzing the requirements and looking at alternatives as well before settling down.

The end result is very lightweight compared to VS and does almost everything users require. VS still starts a lot slower than VSCode for one.

<comment><USER12> Maybe I'm an outlier, but I open/close my editors just as often as my file manager.

The main benefit of Electron is the community. Everybody knows HTML/CSS/JavaScript, so can write extensions / customisations. If I were Microsoft, that's how I would have justified Electron.

Still, I personally much prefer Sublime Text :-D

<comment><USER5> My Spacemacs session often grows weeks old :)

Emacs also has a client/server architecture so I can spawn the emacs daemon and then connect to it from anywhere.

We have a few people in VSCode at work, a few in Sublime and yet more in Atom. They're all very happy with their setup :)

</comment></comment></comment></comment><comment><USER13> > For the love of God, learn something else. Learn how to use GTK or Qt. Maybe > Xwt is more up your alley. How about GNOME's Vala thing? Learn another > programming language. Learn Python or C/C++ or C#.

All of this takes time. If you want to launch an app on multiple platforms, Electron is a very time efficient way to do this. Obviously native apps for every platform would be ideal but not everyone has the resources for that.

> Let me be clear about this: JavaScript sucks. It's not the worst, but it's > also not by any means good. ES6 is a really great step forward and I'm > thrilled about how much easier it's going to be to write JavaScript, but > it's still JavaScript underneath the syntactic sugar.

Use something like Typescript or Flow then. The above is like saying C++ sucks because assembly is a bad language to code in.

</comment><comment><USER14> This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size.

If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone.

I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross- platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw).

Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable.

That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?

<comment><USER15> > If writing software is about making users' lives easier, happier, or better, > though, I think we ought to optimize for that and that alone.

That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier.

> Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ > is

C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool.

> That said, the article does skirt an issue I've thought about a little, and > I'm interested to hear others' takes.

Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you:

About electron: "One of the slowest, least memory efficient [...]"

About terminal: "They've taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. "

About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]"

The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone.

The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?

<comment><USER14> > just choosing electron won't make your users happier.

Ah thanks, I lost some clarity in a post-write edit. My point wasn't that choosing electron would do that, it was that we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions.

Re: C++: You may be right, but we can't deny that popularity and cool factor has a significant effect on hard metrics--eg, more frameworks, more libs, more components == faster dev speed & iterations, which I think is a good thing. ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool factor' has made it the de facto choice for designers, which has resulted in a bulk of the latest designer tools being Mac only (a problem which, coincidentally, electron & its ilk aim to solve).

Last: no, it wasn't a joke. I know what the article said. My point was that the point of socioeconomic accessibility was mentioned, as you note, in the last line, but for the most part, the supporting data were more asserted as intrinsically bad. If it was a key argument of the author's, I think the data would've been tied coherently to the conclusion instead of requiring a diligent reader such as yourself to farm & cobble them together into a patchwork argument.

So, if you'll forgive me for borrowing a little of your snark: next time you google a word, for instance, 'skirt', you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here.

To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users in the environments they prefer easier is probably good, but the extent to which this trades off with accessibility is unclear to me."

<comment><USER15> > you should probably prefer the first definition ("go around, past the edge > of") instead of the fourth definition, as you've done here.

That was the third definition. The first definition was "a woman's outer garment fastened around the waist and hanging down around the legs." /snark

> we should look more at end-user satisfaction and less at often pedantic > technical analyses of solutions.

They aren't orthogonal. User satisfaction comes from a smooth experience. Regardless of how shiny something is, if it slows down the rest of the system (or is itself laggy) users will notice. I choose to run foobar instead of other music players because it's small and fast.

> are we further limiting a great web UX to those with the money to afford the > latest laptops?

This is what infuriates me. People have been talking about how the "free lunch" is over [1] since 2009. About how CPUs have stopped getting faster, and how we should make the best out of the current hardware by learning to paralelize. Yet javascript is the most popular language and it's fundamentally single threaded. High quality software is not about having "a great web UX". VLC doesn't have it (great web UX). Blender doesn't have it. Intellij IDEA doesn't have it. And they're not only extremely complex and efficient softwares, they also have great UIs. Our computers are extremly powerful. The fact that someone would wonder if they're not enough to run pretty clipboard managers and fancy text editors is making me cringe.

[1] [http://www.gotw.ca/publications/concurrency- ddj.htm](http://www.gotw.ca/publications/concurrency-ddj.htm)

</comment></comment></comment></comment><comment><USER16> As some of who's had to support Qt, wxWidgets and other crazy x-platform UIs I find electron refreshing.

Heck, I've got Rust talking to node.js in it. Elm for the front-end and Rust for the processing, it's a surprisingly pleasant development experience.

<comment><USER17> Hey, is this open source? Sounds very cool. If not, can you point me towards any open source apps that are using a similar approach?

<comment><USER16> Not yet but it will be once it's a little further along.

Rust -> Node -> Rust is pretty simple, just expose a c api and wrap it with node-ffi. Then I have the main thread piping messages over to the relevant windows straight into Elm ports.

Nice bit is you can pass callbacks into Rust that calls js via c function pointers. Saves a ton of time marshaling data and is more efficient.

</comment></comment></comment><comment><USER18> This guy is doing his best to make sure we can't have nice things.

> We use [JS] because we have no choice (people who know more than just > JavaScript know this). The object model is whack and the loose typing is > whack and the DOM is super whack.

Moot point. I use React + TypeScript. Good types and barely ever work with the DOM. If you don't like TypeScript, your favorite programming language probably compiles to JS anyways.

> The reason people choose Electron is because they are too lazy to learn the > right tools for the job. This is the worst quality a developer can have.

I agree that bundling a copy of chromium for a todo list app or clipboard manager seems wasteful. But that's an edge case, most people build actual applications. If I'm building a non trivial cross platform app, I'll be orders of magnitude faster on the web stack. I'm not lazy, I just don't want to waste months of my time learning arcane APIs because anything else wouldn't line up with the author's point of view about what the "right" tool is.

</comment><comment><USER19> "If you want to make a quick little app, instead of using something convenient that you know, you should learn a REAL language like C"

Why is this garbage on the front page? Stop giving condescending people like this a platform.

</comment><comment><USER20> > For the price of 200 extra MiB of disk space and an entire Chromium process > in RAM and on your CPU, you get a less capable GUI that saves you from > having to type the -ss and -t flags yourself.

Cool. I remember when Handbrake first came out, and 'make video go on iPod' went from some long winder research into ffmpeg flags to clicking a button that says 'output for iPod' [1]. This sounds similarly timesaving.

[1]. yes, iPod. Showing my age.

<comment><USER21> >[1]. yes, iPod. Showing my age.

That was, what, 9 years ago? I realize it's an eternity in the average JS framework lifecycle timeframe, but come on.

</comment></comment><comment><USER22> I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.

<comment><USER23> What are your problems with Qt?

I was using PyQt, and I found it nice (Qt's integration is good).

<comment><USER24> C++ Qt, I've found, is an entire separate beast.

It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list<> are the same, same for QMap and so on and so forth. So data communication is already a pain.

We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like: connect(sender, SIGNAL (valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) );

This is less than ideal.

<comment><USER25> When having to deal with compilers that barely support a mix of C++98 and C++03, Qt is quite good.

STL wasn't always here and still isn't in some embedded platforms.

</comment></comment></comment></comment><comment><USER26> This article makes a good point, but what's the alternative? There is no good cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very good. Electron at least has the advantage of being fully cross-platform and not having to learn a whole new universe if you're already familiar with the web.

<comment><USER27> For cross-platform apps, Qt is the best I've used. But it does have its warts, and it is big, it will probably bloat your app by about as much as Electron does.

But yeah, there's no one clear winner, which means that Electron is not a uniquely bad choice. Sure, it might be a little heavyweight for a really small simple app, and if you're not aiming for something cross platform your native widget toolkit might be a better idea.

</comment></comment><comment><USER28> I look at Electron apps the same way I used to look at Adobe Air apps. Any League of Legends player knows how bad the launcher is - 80% the fault of Adobe Air.

Sure it was easier to build, but your users suffer for it. Electron apps are pretty terrible performance wise, and you can immediately tell it's an Electron app.

\- Atom

\- Slack

\- GitKraken

All of these apps have 'tells'.

<comment><USER29> Yea but look at VSCode, definitely an exception to this. The feel of code vs atom is night and day to me.

<comment><USER28> Props where it's due! VSCode definitely feels native.

<comment><USER30> VSCode certainly proves that Electron is capable of going the distance to making an app that feels like native. And it's a great example to read the source and learn how to do that for your own app. It's just a simple matter of programming. ;)

</comment></comment></comment></comment><comment><USER31> I've been fighting with this for a while now. I think the only good reason to use something like Electron is if you need to get a cross-platform POC up and running quickly.

I am currently trying to make a GUI to compose and render Terraform assets in a similar manner to AWS CloudFormation's visual designer, and I've spent an eternity trying to devise the best way to do this (this is mainly driven out of boredom more than anything else...Terraform works just fine as is). As much as I don't want to use Javascript and the cancer that is it's dependency management, the web stack is proving to be the path of least resistance thus far. Although I still don't understand why you need to download half of the known internet to install gulp and babel locally.

I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms?

<comment><USER15> > I'm a GUI novice. Is there any cross-platform software that generates a true > native UI on target platforms?

wxWidgets does

</comment></comment><comment><USER32> Well, that was a waste of time, the article is more a rant than anything else. I can understand that some piece of technology will not like everybody, but not spending any time giving proper alternatives. Not to mention that the header seems click bait since it's an opinion article, not an actual security risk.

</comment><comment><USER33> The problem is there is no really alternative. Or what alternatives exist to write good looking, cross platform desktop applications with reasonable effort? I don't think there really is one. Another think is the huge amount of dependencies typical electron apps have (or in general node applications). 500-1000 packages is not unusual. Thats ridiculous for a simple desktop application

</comment><comment><USER34> The argument that the only advantage of Electron is cross platform portability is not true. Electron tries to duplicate what is already a main stream approach for deploying backend services. The only reliable and sane way do have a stable backend is to explicitly control and isolate all dependencies of the backend services by using virtual environments, Docker or virtual machines. Most people no longer think that it is a good idea to run multiple services on the same server, globally 'pip|npm|bundle install' packages that one of these services needs and hope for the best.

Electron tries to do just that on the desktop. It packages all the dependencies that the application needs together with the application and installs them in an isolated app folder (not affecting any other app). It enables easy automatic updates of the whole environment without worrying that the update will break other apps or will not work because some user happens not to have some system library.

Sure, this is much earlier stage than with backend services. Ideally Electron could ensure that identical dependencies that are shared between different apps are not installed multiple times, the way Docker does it. Even without such sharing I think that benefits of the Electron approach justify additional MBs on disk.

<comment><USER35> We've been doing self-contained app distributions, with all third-party dependencies bundled, for well over a decade, especially on Windows. But Electron does make it quite easy to package an app that way.

</comment></comment><comment><USER36> If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.

<comment><USER37> What if there was a centralized way of accessing HTML + CSS + JS applications? Instead of installing apps, you could just... "download" the necessary files to execute them? Perhaps even on demand from centralized.. "servers"?

<comment><USER38> I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline.

I haven't seen many examples of people using Electron to make applications that really should be web apps instead, but more for packaging web apps with native enhancements. Often I'd prefer a "proper" native app, pushing even more features in the browser IHMO is not the answer.

<comment><USER39> >I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline.

Ctrl+S -> Save whole webpage

alternatively get the Webpages source code.

</comment></comment></comment></comment><comment><USER40> Stupid essay is stupid, but I'm glad it pointed me to lossless-cut because that tool is great! The author completely misses the point of Chromium in berating lossless-cut for being "a graphical UI for two ffmpeg flags". Yes, exactly, it's a GUI that lets you cut video to the precise frame you want to. That exactly solves a problem I've had for a long time; I've been using a horrible ffmpeg command line alias (along with preview in VLC) for a year now. He's a little right about "It doesn't even use ffmpeg to decode the video preview in the app"; that would be useful for supporting weird formats that Chromium doesn't. But for common formats lossless-cut is great. It's at [https://github.com/mifi/lossless-cut](https://github.com/mifi/lossless-cut)

</comment><comment><USER41> See, I totally agree with this essay.

But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example.

Maybe someone should write an intro to native GUI programming for JS devs.

<comment><USER42> What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can do Java, and from my experience, it's way better than swing or awt.

<comment><USER43> Purely out of interest, because I might have used one without even realising it, but could you link some desktop applications written in Java that haven't been sluggish as hell or a bit broken feeling?

<comment><USER44> JEdit? Any IDE by IntelliJ? These are not JavaFX (its fairly new), but you asked for Java.

<comment><USER43> IntelliJ is a good IDE, but it's UI is far from not-sluggish.

</comment></comment></comment></comment></comment><comment><USER45> I have been wondering...does Slack freeze for like a couple of minutes a couple of days a day for someone else?

I am on win10, on pretty hefty machines. No idea if it's because Electron or something else, but it's really annoying. I could not find any trace of issues in the event viewer etc.

</comment><comment><USER46> Calling people lazy should also be considered harmful. Please stop doing this.

Time is finite, and not all of it should be spent programming.

</comment><comment><USER47> Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron or using a WebGL canvas instead of a native graphics API. The article highlights cases where they price was paid, but the app was still platform specific.

<comment><USER48> Well, it's the same logic - so almost _by definition_ it should be platform- independent. People are too lazy to introduce proper abstraction between what the application does and what it shows on screen, and suddenly porting is hell.

Either way, Electron sucks because it ships a whole goddamn browser to give you _just_ portability; you have to still pile on a ton of JS and CSS hacks to get a decent-looking SPA UI out of it, which you'd get for free with any proper GUI runtime. All that waste because people want to write JavaScript (which I understand - I have my favourite language I'd love to write more too) and this was _the most brute-force way to allow it_.

Embed a system webview if you must, don't ship the goddamn browser!

</comment></comment><comment><USER49> The fact that electron is easy enough to write trivial apps while at the same time powerful enough to give us VS Code is in my book SPLENDID.

If the trival app is too big for a trival app - who cares. The fact is there is now a serious contender in the cross-platform space that so far has been mainly occupied by Java. Java cross-platform is neither easy nor lightweight. And from what I have seen so far getting started with Electron looks a lot easier.

</comment><comment><USER50> There are a lot of shitty half working apps, and there always will be.

</comment><comment><USER5> I can't help but feel as if the author can't make the distinction between a platform and the software written for it. People have been misusing platforms ever since they existed. Its not because someone used Electron to build a console that Electron is bad in and of itself, it just means someone used the wrong tool for that specific job - or maybe that fitted all their requirements in which cause the author is just dismissing the work with no clue about its context.

I also can't help but feel as if the author is a beginner developer lacking a huge amount of context and experience. Saying "Electron enables lazy developers to write garbage" displays a huge misconception about software development in the very first place - garbage will be written no matter the language or platform.

Alls the article did was remind me that those who can, do, and those who can't, blog.

<comment><USER51> And those who really can't post snarky comments on HN.

</comment></comment><comment><USER52> The only viable alternative is Qt, and it is almost as big and offers a less familiar programming model.

Native is only an option if you want to rebuild your app UI from scratch a minimum of twice and never support Linux or other less common desktops.

UI development has always been in fragmentation hell.

</comment><comment><USER53> Yeah no. Electron is fine to write desktop apps.

I've seen native app with more ugly UIs and being laggy, etc... For many apps Electron is fine and will perform as well, or even better than native apps (just because, developers you know).

</comment><comment><USER54> Honestly I think this is a symptom of the lack of really good GUI toolkits that let you define the UI in an easy-to-use and powerful language. There's Qt & QML, but that's about it, and to be honest QML is still pretty immature (try doing a custom control with text, or any kind of text editor in QML).

I really hope Rust or Go get great native GUI toolkits soon with nice declarative layout languages, but until that happens it is hard to get too angry at people using the wrong tool for the job because the right tools just aren't that great.

</comment><comment><USER55> I have a windows store js/html app which I plan to re-release on electron. It features a rich text editor and a few other features. I want to release on Linux and mac os. Should I go away and learn qt/gtk/wx? Restart the whole project in Java?

The idea that I might choose electron for ease/speed of development rather than use a leaner platform is being shit all over as a "business" decision. Not a "I don't have enough free time to learn two new languages and ui systems code three new apps" decision.

</comment><comment><USER56> I dislike JS just as much as the next guy but the only real contender on the list is Qt. Which you need to license for commercial development. Furthermore, even though I like to think that I'm ok in C++, I would really think twice before using it on my next project these days.

The JS performance issues should go away for the most part when wasm is standard. Also a lot of people write some compile to JS language, not JS, so I think that most of the points of this blog will be rendered moot in the near future.

<comment><USER57> If you're doing commercial development, why is a license (and the attendant support) a big deal? Its cost in relation to that of your developers is neglegable.

Or is the cost of the license really that prohibitive for a well supported and performant piece of software?

[EDIT]: I found the pricing after a bit of creative googling: Startups is about $1,000 a year, non-startups are about $3,500 a year. Even without the discount, that's roughly equivalent to a month of one developer's time. IMO, not a terrible deal, for something you can freely license and use for cross platform development.

</comment></comment><comment><USER58> We need to stop reading such posts. "Everything sucks because I say so". Technology is really fair. At the end we WILL use what matters the most and has the overall best tradeoffs. I don't like it when people use the expression "best tool for the job". Like you used every other available tool out there and you found the best one...no you haven't.

</comment><comment><USER59> Considered Harmful essays considered harmful.

[https://news.ycombinator.com/item?id=9744916](https://news.ycombinator.com/item?id=9744916)

</comment><comment><USER60> For me the title evokes "Considered harmful essays considered harmful", which suggests that perhaps "benefits and disadvantages of Electron" would have been a better essay.

[http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

</comment><comment><USER61> Just because a particular technology is not the "right" tool for every job doesn't make it harmful...

</comment><comment><USER62> I'm a bit late to the party, but there are active React Native ports for both OSX and Windows.

Using them could be a good solution for targeting OSX and Windows and reusing logic from your web React app without having to deal with the overhead of Electron.

</comment><comment><USER63> Another example of "'____ considered harmful' considered harmful".

<comment><USER64> Eric Meyer put it best, I think. Time for a repost: [https://news.ycombinator.com/item?id=13031883](https://news.ycombinator.com/item?id=13031883)

</comment></comment><comment><USER65> Web browsers should have integrated functionality to run some websites as standalone apps (anyone remember Prism?). That way we wouldn't need to install yet another copy of browser with each app.

</comment><comment><USER66> OT: what's the difference between Electron and Electrode?

<comment><USER67> Electron is a cross-platform desktop framework based on a web stack.

[http://electron.atom.io/](http://electron.atom.io/)

<comment><USER66> How does it compare to [https://github.com/electrode- io](https://github.com/electrode-io)

<comment><USER38> Electrode seems to be for "normal" web sites/web apps, Electron is for packaging HTML+JS as desktop apps.

<comment><USER66> Okay, thanks.

</comment></comment></comment></comment></comment><comment><USER68> While I agree with his general idea that Electron is usually not the best tool for the job, I think he's overestimating JS as the reason that people choose Electron. It's not because of JS, it's because of HTML and CSS, which aren't that bad comparing to other tools we have (especially since Flexbox). I think most people would love to write desktop apps using HTML and CSS, while using anything other than JS to do the logic. We're just... not there yet.

</comment><comment><USER69> SirCmpwn, you'll understand more about trade-offs when you finally have commercial success with one of your projects.

It's too easy to lambast Electron and "lazy developers" when you've never had business concerns trump technical ones because none of your work ever tried to run that gauntlet.

I had to chuckle to myself when I saw that your GitHub bio is:

        > I make unoriginal projects with better code than
        > the thing they rip off. I'm available for hire.

</comment><comment><USER70> what is electron?

<comment><USER23> Downvoted; this question can easily be answered via a search engine.

<comment><USER71> Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question.

To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment.

More info here: [http://electron.atom.io](http://electron.atom.io)

<comment><USER23> How would I say my message without being snarky?

<comment><USER71> If all I can add to a discussion is "Just google it", I just won't respond. For better or for worse, people aren't going to respond by saying 'By golly, you're right! I'm so lazy, but from now on, I will google stuff first instead of asking questions." They're just going to say basically "What an asshole, fuck this guy.

Maybe he wants an answer that is curated and summarized by a human, not a litany of links where you don't know what to focus on. For example, when I asked what dependency injection is, some kind stranger responded "It's a million dollar term for a 5 cent concept. Pass objects as arguments to functions instead of instantiating them inside." Of course, this is a limited definition, but it was put into layman's terms and it answered my question. From that answer, I was able to really learn what it was instead of being stuck on phase 1 of understanding.

When you're online, it's much easier to come off as a dick than it is in person so what I try to do is imagine someone coming up to me earnestly and genuinely asking the same question and respond thusly. Accordingly, when I know I'm asking a simple question, I add self-deprecation to the beginning. Example: "I have the technical and programming acumen of a bag of rocks, so excuse my elementary question, but..."</comment></comment></comment></comment></comment>


Why all programmers should earn their master's - <AUTHOR> http://qz.com/414542/why-programmers-should-get-a-masters-degree/ <comment><USER2> When everyone has a Master's, employers will start stating Phd as the minimum.

In San Diego, most large companies won't even talk to you if you only have a Bachelor's Degree.

Upskilling: A pox on America. What about hiring for potential, and training new hires? That was what used to happen.

</comment><comment><USER3> I'd say plan your retirement by 40 in Globalization;</comment>


Artificial Intelligence Swarms Silicon Valley on Wings and Wheels - <AUTHOR> http://www.nytimes.com/2016/07/18/technology/on-wheels-and-wings-artificial-intelligence-swarms-silicon-valley.html <comment><USER2> Just the beginning. Software is eating the world, and more and more software is powered or guided by machine intelligence whose behavior adapts to new data.

AI will be everywhere.</comment>


200 Million Workers Want Windows 8 Tablets, Not iPads (Forrester) - <AUTHOR> http://readwrite.com/2013/02/04/200-million-workers-want-windows-8-tablets-not-ipads Two hundred million IT workers want Windows tablets, a report for Forrester claimed Monday, quite a bit more than the 900,000 Surface RT tablets that IDC estimated have already been sold into the channel. <comment><USER2> 200 million, really? And how many Directors or Vice Presidents make the purchasing decisions for those 200 million? A lot less, you say? Very good! The folks who got this PR Hit for Windows 8 Tablets can focus on those agents who make the decisions that the 200 million have to suffer with.</comment>


TempleOS: Installation - <AUTHOR> https://christine.website/blog/templeos-1-installation-and-basic-use-2019-05-20 <comment><USER2> Terry was a nut, but he did a pretty good job of getting the word out about his magnum opus. Over several years, he alternated between sincere advocacy and unhinged abuse in trying to get my website OSNews to cover his OS development efforts more widely. Eventually, one of our volunteer editors patiently worked with him to produce an article about it:

[https://www.osnews.com/story/23796/recreational- programming-...](https://www.osnews.com/story/23796/recreational-programming- with-losethos/)

I just spent a few minutes reviewing my email archive of correspondence with Terry, and it warms my heart a little, even though at the time is was kind of terrifying.

<comment><USER3> Would you be able to publish said letters somewhere for posterity?

<comment><USER4> When I die I hope people don't decide to begin sharing my private conversations.

<comment><USER5> When you die, there will be nobody to care about that

</comment></comment></comment></comment><comment><USER6> I learned today that Terry died. There is mist in my eyes and pain in my heart. I wish I could have helped him.

Sorry Terry, you were born with a loaded gun. I wish we could have healed you. I wish we could have taken care of you. I wish you were still here to share your gift with the world.

I'll install Temple OS on a Raspi in your honor and memory.

edit: [https://youtu.be/bQlE2C7K7Kc](https://youtu.be/bQlE2C7K7Kc)

<comment><USER7> I felt similarly when I heard the news.

I can't explain the sadness I felt when I learned that 4Chan brigades are largely responsible for how quickly his situation deteriorated.

For those who, like me, didn't know, he had begun live-streaming, where he would take call-ins to his landline. It's there that a concerted campaign to get Terry to alienate himself from his parents (with whom he lived) and stop taking his medication. This is not to mention how they egged on romantic feelings for a YouTube personality who they would later impersonate and torture him with in awful ways.

All this led to Terry's parents being unable to house him. They were very old and the situation became impossible. Terry survived on the streets for sometime, meeting up with (genuine and loving) fans along the way. Terry sadly was struck by a train.

We were able to celebrate an eccentric and strange life because of the internet. It also ended it. I hope the internet can heal... I know people like you and I hope it can. It didn't here.

If you want to learn more about Terry's life and death, please check out Fredrick Knudsen's video essay. It is in-depth and important, although very challenging because of the subject matter.

[https://www.youtube.com/watch?v=UCgoxQCf5Jg](https://www.youtube.com/watch?v=UCgoxQCf5Jg)

Finally, if you feel like you or someone you care for are in crisis, or might be soon, consider speaking to the folks at NAMI in the US. If you're not in the US, they can direct you to people in your country.

1-800-950-NAMI (6264) or email@example.com

<comment><USER6> This makes me so angry. Usually, mob justice is a bad thing but there are few legal recourses here; can we make sure that the stain of this man's death never washes away from the people who perpetrated this act?

If the live streams are still up, can we (with the family's blessing) find the people who called in to hurt this man? Would it be okay to publicly name them and link to his suicide and what each individual did?

It feels odd to ask for a punishment via the commons, but this man deserves some measure of justice for his passing.

</comment></comment></comment><comment><USER8> I sincerely enjoyed Terry A. Davis' videos on youtube.

Yes, You need to actively remember that you are dealing with a person with severe and possibly badly treated/untreated mental illness, and I say this because of the random bouts of aggressiveness and also blatant use of curse words such as n*gger and etc. Also his very skewed political views and whatnot.

But if you can keep that in mind ("I am dealing with a sick person") and forgive his behavior during those bad events, you'll be able to "savor" his videos in a very technical way. The guy was truly a genius on its own league, a fact that, together with his mental illness, probably hurled him further into loneliness

(I am sure several bright people here on HN can relate on how being different or bright sometimes equals loneliness, specially during early years).

So please, try to watch his videos with these guidelines in mind, you'll surely be able to get some good lessons about delivering a vision, lowlevel compiler work or algorithms into your own craft.

<comment><AUTHOR> I'd love to take those videos and turn them into proper coherent blogposts. That's my main goal for the rest of this series.

</comment></comment><comment><USER9> I don't like running TempleOS on hardware or in a full fledged VM(Seems like overkill). I would like to make an alternate virtual machine to run TempleOs programs on, in Javascript using a Canvas element for UI. I am unsure if there are constructs which TempleOS uses which are unrepresentable in a virtual machine built inside of a javascript virtual machines - like threads, interrupts, etc. I think events could be wired up as interrupts and there is probably a way to simulate threads in a single thread but I have no experience here. If anyone has any insight into what the challenges of such an approach would be, I would love to hear them.

<comment> yjftsjthsd-h Philosophical objection: that is exactly the opposite of what TempleOS is about.

Practical objection: By the time you've done that, you'd have written a complete IBM-PC-to-browser compatibility layer. ... This would be super cool if it worked, I'm just sceptical.

<comment><USER10> x86 emulators in browser are available: [https://copy.sh/v86/](https://copy.sh/v86/) [https://bellard.org/jslinux/](https://bellard.org/jslinux/)

These won't run TempleOS though, because it requires x86-64.

<comment> yjftsjthsd-h Didn't sound like OP wanted a VM; they wanted a reimplementation or compatibility layer (like wine or wsl).

</comment></comment></comment></comment><comment><USER11> Several interesting videos have been made about TempleOS and Terry's life since he passed away last year:

[https://www.youtube.com/watch?v=V6HlbpczpDM](https://www.youtube.com/watch?v=V6HlbpczpDM) (12 minutes)

[https://www.youtube.com/watch?v=UCgoxQCf5Jg](https://www.youtube.com/watch?v=UCgoxQCf5Jg) (1.5 hours)

</comment><comment><USER12> Have there been any major improvements/updates/upgrades to TempleOS in the last year or so? Haven't seen the author of the OS posting around much in that time.

<comment><USER13> Terry Davis passed away about a year ago: [https://www.thedalleschronicle.com/news/local/man-killed- by-...](https://www.thedalleschronicle.com/news/local/man-killed-by-train-had- tech-following/article_57e12c9f-d06c-5356-8a1a-f8e4322bd573.html)

<comment><USER12> Bummer. Thanks.

</comment></comment></comment><comment><USER14> It seems like there is ample opportunity for someone to issue a more polished TempleOS with a little less idiosyncrasy and a little more userland but still preserve the quick and dirty feel, the tightly integrated compiler and runtime and the minimal separation from the metal that makes it unique.

</comment><comment><USER15> QEMU and KVM also support pcspkr audio, so they should be perfectly suitable to run TempleOS.

<comment><AUTHOR> Does it support emulating one for a MacBook that lacks the hardware?

<comment><USER15> Yes, it's certainly using whatever sound hardware you have to emit beeps and blips :)

</comment></comment></comment><comment><USER16> Man I miss Terry. His live streams were fascinating, often sprinkled with real insights among the insanity. Shame it all ever unfolded the way it did.

<comment><USER17> As I don't have time to go through his oevre could you perhaps pass on to us a few insights of his? TIA

<comment><AUTHOR> \- Less is more

\- Context switching doesn't have to be expensive

\- Compatibility is nice, but so is speed

\- Know your codebase well enough to be able to jump to random parts of it and explain what is going on</comment></comment></comment>


Cost of Coworking Space vs. Your Own Office - <AUTHOR> http://blog.spacelist.ca/2013/07/19/when-its-time-to-get-your-own-office-the-math/

<comment><USER2> The line about _a person generally takes up ~150 square feet in an office_ , might not be so accurate. I've seen 4 people or more crammed like sardines into that space [1, 2, 3]. Hell, I used to be one of them. Throw in a couple fish tanks and a bean bag chair just for the hell of it. Extra office space is nice, but at a growing company, _there is always room_.

Just google images "startup office".

[1] [http://images.techhive.com/images/article/2013/03/working2-f...](http://images.techhive.com/images/article/2013/03/working2-fullres-100031101-large.jpg)

[2] [http://cdn.thenextweb.com/wp- content/blogs.dir/1/files/2012/...](http://cdn.thenextweb.com/wp- content/blogs.dir/1/files/2012/09/02.-LayerGloss-1-520x333.jpg)

[3] [http://2eq9hztv2wc1k6odx469m9znq0.wpengine.netdna- cdn.com/wp...](http://2eq9hztv2wc1k6odx469m9znq0.wpengine.netdna-cdn.com/wp- content/uploads/MariaOfficeShot-1024x690.jpg)

</comment><comment><USER3> The whole series

When to Get Your Own Office – The Alternatives: [http://blog.spacelist.ca/2013/07/02/when-to-get-your-own- off...](http://blog.spacelist.ca/2013/07/02/when-to-get-your-own-office-the- alternatives/)

When to Get Your Own Office – You're On The Hook: [http://blog.spacelist.ca/2013/07/07/when-to-get-your-own- off...](http://blog.spacelist.ca/2013/07/07/when-to-get-your-own-office-youre- on-the-hook/)

When It's Time To Get Your Own Office – The Math: [http://blog.spacelist.ca/2013/07/19/when-its-time-to-get- you...](http://blog.spacelist.ca/2013/07/19/when-its-time-to-get-your-own- office-the-math/)

</comment><comment><AUTHOR> @westcoastjustin For sure! I used 150 Square Feet per person, but it varies widely. Really luxurious offices can be easily over 200 SF / head, and on the tight side you can get down to ~75 SF.

<comment><USER2> Yeah, I get you. I've had a ~150+ office for many years now, and I still think, man there is no one in here ;)

</comment></comment><comment><USER4> to;dr at around 8 team members it starts to make financial sense to think about your own space.

Aside from financial costs I think there are other non-tangible benefits on both sides of the equation. We love our co-working space but are only 4 at the time. We'll see when the time comes...

</comment><comment><USER5> Hmm, screenshots of tables with red squiggles. What's wrong with <table>?</comment>


Mark Zuckerberg doubles down on universal basic income after a trip to Alaska - <AUTHOR> http://www.businessinsider.de/mark-zuckerberg-universal-basic-income-alaska-2017-7?r=US&IR=T <comment><USER2> It's pretty obvious that Zuckerberg is trying to grow his public image in the national psyche to prepare for some kind of political run in the near future.

He is not doing a good job, tbh, and if anything it's just further solidifying the perspective that he is an out of touch creepo

<comment><USER3> After his message exchange published by Business Insider in 2010 ([http://www.businessinsider.com/well-these-new-zuckerberg- ims...](http://www.businessinsider.com/well-these-new-zuckerberg-ims-wont- help-facebooks-privacy-problems-2010-5)), I think people have a hard time taking anything he says seriously.

Just print and distribute that article to ruin any campaign of his.

<comment><USER4> This must surely alienate potential supporters. I can not imagine someone getting to be US president with such shameful conversations being on the public record.

</comment></comment></comment><comment><USER5> I'm curious, isn't UBI basically untenable without single payer healthcare? Assuming he will be running for president, doesn't that mean he will be essentially a socialist candidate?

<comment><USER6> Socialism is a spectrum. We have a socialized public transportation infrastructure, socialized power industries, socialized water and sewage industries, and a lot more, yet most people don't complain about that. UBI doesn't designate how peoples' income is used, it merely provides a baseline income to facilitate survival at least.

<comment><USER2> Are you really making the argument that government provided services are socialism lite?

So I guess the Romans were socialists then with their aquaducts.

<comment><USER7> Yes, really, they are. And I'm not sure why this stuff is so surprising: one of the strong facets of scandinavian-style socialism is the government services and safety net. Single payer healthcare is often villified as "socialized health care".

I'm pretty sure UBI and healthcare fit into the spectrum.

</comment></comment></comment></comment><comment> io-io2 So, who is exactly going to pay for all of this? How is government going to collect funds in order to dole it out to everyone? Income tax?

Mark Zuckerberg only makes $1 in income from Facebook.

* [http://www.businessinsider.com/mark-zuckerberg-only-makes-1-...](http://www.businessinsider.com/mark-zuckerberg-only-makes-1-a-year-2015-6)

But, before you go feeling sorry for Zuckerberg because he is working for free - for the good of the people, read the next set of articles... It appears that he has set himself up to NEVER pay any tax for the rest of his life.

* [http://www.cnn.com/2013/04/09/opinion/mccaffery-zuckerberg-t...](http://www.cnn.com/2013/04/09/opinion/mccaffery-zuckerberg-taxes/index.html)

* [http://www.nytimes.com/2012/02/08/opinion/the-zuckerberg-tax...](http://www.nytimes.com/2012/02/08/opinion/the-zuckerberg-tax.html?mcubz=0)

It appears that the rest of us will be carrying the burden of UBI if it ever goes through.

</comment><comment><USER8> A thought experiment:

You're currently working in a call center making $9 an hour. You have no degree and marketable skills. Then you find out you're now eligible for a paycheck that is equal to or more than you currently earn. What do you do?

<comment><USER9> Quit the call center job and enroll full-time at the local community college?

<comment><USER10> Seriously, call center job is a dead end job.

If you had the opportunity to go to college and get a trade or degree for a better one this is a good move.

<comment><USER7> Honestly, I've been in jobs that are _much_ more dead-end. The one I worked at provided a really good education benefit with fairly clear ways to get promoted and transferred. I took advantage of those, and eventually got outside the call center. This could be, however, because I worked at a phone company instead of something like a small sales or collection agency.

<comment><USER11> I think the definition of a "dead end job" is one that does not provide clear ways to get promoted.

</comment></comment></comment></comment></comment><comment><USER12> UBI sounds a bit like minimum wage. Our normal tools of analysis will fail to find much of a problem so long as it's only a small difference from how things would have been without it, and a disaster otherwise.

</comment><comment><USER13> UBI is such a crock of BS. It was genius marketing naming it "Universal Basic Income" because it is anything but "universal". UBI is basically all of our current social spending thrown in a huge pot, multiplied by some factor, and doled out without any earmarks on how you can spend it (sure, maybe it is written as some type of negative tax bracket but the end result is basically the same). The more income you report, the less "universal basic income" you receive, while your taxes will skyrocket to pay for all of the new UBI spending. And the more people who decide to opt out of the workforce to pursue their passion projects, the higher those taxes on the working middle class will become. I guarantee Zuckerberg and his ilk will find loopholes to avoid paying a proportional UBI tax to their net worth. Once UBI is really exposed as the huge middle class tax it is, it will go down in political flames.

<comment><USER14> > The more income you report, the less "universal basic income" you receive, > [.

This is a misunderstanding. Under UBI, everybody receives the same monthly UBI. The size of the UBI does not depend on income.

> ..] while your taxes will skyrocket to pay for all of the new UBI spending.

Well, yes. Of course. Somehow this has to be paid for. But this will more probably be paid for by taxing corporations and shareholders instead of labour. For example by using the ~$2.0tn of US companies cash reserves.

<comment><USER15> >But this will more probably be paid for by taxing corporations and shareholders instead of labour.

This is not a good thing. It will discourage investment in the US.

>For example by using the ~$2.0tn of US companies cash reserves.

Corporations have trillions in debt. They need the cash reserves as a cushion to absorb potential losses from a future economic crisis. The economy is less fragile with companies having these cash reserves.

Central economic planning like this, which just assumes "don't worry this will be fine as we take X from Y and spend it on Z" is so reckless. There are always grave negative unintended consequences from forcibly redistributing other people's income/wealth, and if you're not thinking hard about what they may be, you're going to overlook them.

<comment><USER14> > The economy is less fragile with companies having these cash reserves.

Actually, no. Because the stability of the economy depends not on companies but on the cycle of consumption and production. If you have no consumers, there is no reason to produce. If you have no reason to produce, you need no employees. Less people with jobs mean less consumers. And so on.

You see, these humongous cash reserves are actually harmful to the economy. Because they are tied up and not circulating, these cash reserves slow down the flow of money. They impede the cycle of consumption and production.

> There are always grave negative unintended consequences from forcibly > redistributing other people's income/wealth, [...]

And there have been incredible good consequences from forcibly redistributing money from the wealthy. Just look at the Central European States, or the Scandinavian countries. They have very high taxes, highest standards of living for everybody, socialized health care. And very vibrant economies.

<comment><USER15> >Actually, no. Because the stability of the economy depends not on companies but on the cycle of consumption and production.

It depends on a huge number of factors. One event that can destabilize an economy is cascading debt defaults that cause mass bankruptcy.

At the very least you should consider the possibility that your theories on economics are not right, and that forcibly redistributing huge amounts of privately owned income and savings in order to spur hyper-consumerism may cause severe negative unintended consequences.

>And very vibrant economies

With the exception of oil-rich Norway, Scandinavian countries have been economically stagnant since they adopted large-scale welfare programs in the late 1960s. Just like the US and other advanced economies that shifted massively to the social democratic economic model in the 1960s and 70s, Scandinavian countries have seen stagnant wage growth for the last 40 years, and have seen more market oriented economies close the massive gap that used to exist between them and Scandinavian countries in life expectancy, quality of life, per capita wealth and per capita income.

<comment><USER14> > At the very least you should consider the possibility that your theories on > economics are not right, [...]

Of course always consider the possibility that my hypothesis to might be wrong. But I thank you for that advise and will keep it it mind.

> [..] and that forcibly redistributing huge amounts of privately owned income > and savings in order to spur hyper-consumerism may cause severe negative > unintended consequences.

I think you misunderstand the premise of UBI. UBI is not intended to allow for hyper-consumerism. It's purpose is to guarantee a basic standard of living.

> With the exception of oil-rich Norway, Scandinavian countries have been > economically stagnant since they adopted large-scale welfare programs in the > late 1960s.

What makes you think that the Scandinavian countries have been economically stagnant?

> Just like the US and other advanced economies that shifted massively to the > social democratic economic model [...]

I really don't see the US as an example of a massive shift to a social democratic model. The USA has no socialized health care, has no socialized retirement scheme, very limited public education, no socialized child care and certainly no socialized care for the elderly. I could go on, but really; the U.S. of A. is no social democracy.

And yes; wages in the US have stagnated as well!

> and have seen more market oriented economies close the massive gap that used > to exist between them and Scandinavian countries in life expectancy, quality > of life, per capita wealth and per capita income.

If we consider the U.S. as an example of a more market-oriented economy, I don't see them closing that gap. Be it health care, life expectancy, median standard of living, quality of life or gross national happiness - the U.S. of A. seriously lags in all these areas.

Happy to hear your thoughts!

<comment><USER15> I'm glad you are keeping your mind open.

>I think you misunderstand the premise of UBI. UBI is not intended to allow for hyper-consumerism.

I was referring to your argument for redistributive basic income, where you imply that the consumption-boosting impact of basic income would boost economic stability.

>What makes you think that the Scandinavian countries have been economically stagnant?

GDP and wage growth rates.

>I really don't see the US as an example of a massive shift to a social democratic model. The USA has no socialized health care, has no socialized retirement scheme, very limited public education, no socialized child care and certainly no socialized care for the elderly. I could go on, but really; the U.S. of A. is no social democracy.

The only accurate points in this paragraph are the US not having universal healthcare or universal socialized childcare.

The US has a publicly funded retirement scheme (Social Security) and spends more public money per capita than almost any other country in the world on education.

While it lacks universal healthcare, it spends extensively on its public healthcare spending, which covers the elderly, through Medicare, and the poor, through Medicaid.

Moreover, social welfare increased 4.8 percent per year on average, between 1972 and 2011 [1]. This represents a massive shift to the social democratic economic model.

And it's not just the US. Almost all advanced economies underwent this transition over the last 40 years, and it has been associated with stagnating wage growth and less economic dynamism.

[1] [https://fivethirtyeight.com/features/what-is-driving- growth-...](https://fivethirtyeight.com/features/what-is-driving-growth-in- government-spending/amp/)</comment></comment></comment></comment></comment></comment></comment>


Weekend project: web2.0collage creates collage from sniffed browser history - <AUTHOR> http://web2.0collage.com

<comment><USER2> How was the set of "white-list web2.0 related sites" chosen?

</comment><comment><USER3> body { background:#0099FF url('/images/g2.png') repeat-y }</comment>


Aston Martin Is Getting into the 'Evil Lair' Business - <AUTHOR> https://jalopnik.com/aston-martin-is-getting-into-the-evil-lair-business-1837306504 <comment><USER2> I have to admit, I read this and I thought the "lairs" bit must be satire...

But no. They really are calling it a service to design lairs.

[https://media.astonmartin.com/aston-martin-automotive- galler...](https://media.astonmartin.com/aston-martin-automotive-galleries- and-lairs-revealed-at-pebble-beach/)</comment>


Cheaper Robots, Fewer Workers - <AUTHOR> http://www.nytimes.com/2015/04/25/technology/robotica-cheaper-robots-fewer-workers.html

<comment><USER2> Cheaper robots fewer _jobs_ for available workers. If robots displace cheap enough workers from the Chinese hinterlands, this does not bode well for the indias and africas of the world. It used to be labor intensive manufacturing raced to the wage bottom counties, but if they now no longer need labor, what does an ascending India or Africa have to offer their hopeful masses of low education workers....

<comment><USER3> This topic comes up often. This theory has its issues but is mostly solid.

[http://en.wikipedia.org/wiki/Lump_of_labour_fallacy](http://en.wikipedia.org/wiki/Lump_of_labour_fallacy)</comment></comment>


Ask HN: [SOLVED] HN is returning a 503 to my IP. How should I debug this? - <AUTHOR>

EDIT: this page explains all: https://news.ycombinator.com/item?id=4761102
Accessing https://news.ycombinator.com/ from any browser on my local network returns either a 503 error or a blank page. Of course, I can access the site through a proxy (hello).
Curl looks a little strange:

  $ curl -I https://news.ycombinator.com/
  HTTP/1.1 501 Not Implemented
  Server: nginx
  Date: Tue, 30 Apr 2013 09:49:55 GMT
  Content-Type: text/html
  Content-Length: 174
  Connection: close
 I can ping it fine:

  $ ping -c 4 news.ycombinator.com
  PING news.ycombinator.com (126.96.36.199) 56(84) bytes of data.
  64 bytes from 18.104.22.168-static.reverse.softlayer.com (188.8.131.52): icmp_seq=1 ttl=50 time=152 ms
  64 bytes from 220.127.116.11-static.reverse.softlayer.com (126.96.36.199): icmp_seq=2 ttl=50 time=152 ms
  64 bytes from 18.104.22.168-static.reverse.softlayer.com (22.214.171.124): icmp_seq=3 ttl=50 time=144 ms
  64 bytes from 220.127.116.11-static.reverse.softlayer.com (22.214.171.124): icmp_seq=4 ttl=50 time=144 ms

  --- news.ycombinator.com ping statistics ---
  4 packets transmitted, 4 received, 0% packet loss, time 3003ms
  rtt min/avg/max/mdev = 144.188/148.436/152.573/3.952 ms
 I'm reaching the limits of my network debugging talent. What can I do next? <comment><USER2> I can access HN just fine, but I get the same result from curl:

      $ curl -I https://news.ycombinator.com/ -k
      HTTP/1.1 501 Not Implemented
      Server: nginx
      Date: Tue, 30 Apr 2013 09:59:39 GMT
      Content-Type: text/html
      Content-Length: 174
      Connection: close

You could try doing custom HTTP requests via telnet:

      $ telnet news.ycombinator.com 80
      Trying 220.127.116.11...
      Connected to news.ycombinator.com.
      Escape character is '^]'.
      GET /

      <title>301 Moved Permanently</title>

301 Moved Permanently

nginx

      Connection closed by foreign host.

Since HN redirect everything to HTTPS it doesn't tell you much, but it can tell you for example whether a connection to port 80 is going through.

Edit: You have to type the "GET /" <return> part, in case that wasn't clear. The rest is server response.

<comment><AUTHOR> Thanks. I get exactly the same telnet results as you.

Hmm...

</comment></comment><comment><USER3> You could try what is detailed here:

<https://news.ycombinator.com/item?id=4761102>

</comment><comment><USER4> Were you by any chance spidering the site from the same IP?

<comment><AUTHOR> No. I can't think that I was doing anything like that at all. I even subscribe to the RSS feed from a different IP and read that over IMAP!

<comment><USER4> Sometimes a browser crash and subsequent restore with a lot of HN tabs open will trigger an IP ban.

HN is finicky, hard to know for sure what caused this.

<comment><AUTHOR> Ah, that sounds like a distinct possibility! I almost permanently have boatloads of tab open.

Do you know what I can do about it? Is the ban temporary?

<comment><USER4> I think it times out after a while, it's been mentioned before on HN:

<https://news.ycombinator.com/item?id=4761102></comment></comment></comment></comment></comment>


Devil's advocate on Twitter's OAuth change - <AUTHOR> http://www.marco.org/2011/05/19/twitter-dm-oauth-requirement <comment><USER2> I'm annoyed by the change. I was the DevNestSF meetup last week though at TwitterHQ and they said they didn't mention that were going towards doing this and instead praised the developer community for making them what they are.

When they surprised us with this, they claimed it was because most users didn't realize that they gave up that level of access to their account. This change allows them too, but at the cost of bad UX for mobile and native apps, while breaking all existing apps so far.

They moved the deadline back 2 weeks. That gives you less than 4 weeks to make the changes and if it's iOS, you have to get the app approved by Apple which takes 1 to 3 weeks (accounting for one possible reject and Apple being slow).

Then you have to hope that all your users upgrade right away and when they do upgrade they have to reauth everything again with the crappy experience.

These UX issues were what drove the design of xAuth in the first place durning the basic auth switch. xAuth was manually approved and was for clients and not for services that had a web side. These clients are more likely to need DM than most simple web app tools, but xAuth retroactively and going forward doesn't get DMs.

This will break TweetBot, older Seesmic clients, Twitalator, Twitterific, TweetDeck, TwitDroid, etc. Even the official Twitter client (formally Tweetie) would break because it uses xAuth but I'm sure they are hard coding exceptions for different clients.

<comment><USER3> The official apps get an exemption (some would say unfairly) from the new permissions model.

<comment><USER4> How is it unfair? Read the post again.

This is to clarify permissions users are giving third parties. With the official client, there _is no_ third party.

</comment></comment></comment><comment><USER5> Sure, it's Twitter's service to do with as they wish. I hope they have a nice time with it. Over the last few months, they've done a great job of convincing me that I don't need Twitter as a user and that I should absolutely avoid them as a developer.

<comment><USER6> I made a plugin for wordpress based on the twitter API. Sure, there was a time when an abrupt change in 2010 broke my code. I got introduced to JSON when I fixed it, so I guess I'm OK with the experience now that it is behind me. This DM change doesn't affect me.

<comment><USER5> Yes, Twitter is interested in keeping casual API developers such as yourself. It's the people who wish to make full Twitter clients or base businesses upon their API who are being made to feel unwelcome.

</comment></comment></comment><comment><USER7> I followed till I came to "Twitter isn't ours".

I don't know if Twitter's particular changes here are desirable or not. But if company is also providing a messaging utility that millions of people contribute content to and that other provide enhancements to, then "we" sure as heck _should_ criticizing what it is does, deciding whether it is worth "our" while and so forth. If "we" don't, "we" will become serfs to those convenient information providers.

Certainly, "twitter isn't ours" so we can't sue them or immediately fire whoever made this decision. Our options include accept-whatever-without-a- beep(or-a-tweet), criticize and suck-it-up as well as criticize-and-abandon. And latter options seem reasonable.

<comment><USER4> Are you paying Twitter money to use it? No? Then they are perfectly justified in ignoring you.

Remember this quote: "If you are not the customer, you are the product."?

<comment><USER5> Any money Twitter makes is a result of Twitter having users. It doesn't matter if they're selling member data or charging for the service: they need people to use the service, one way or the other. If they wish to have me in their inventory to 'sell', they'd better provide a service I wish to use. Yes, free members are customers.

What happens to businesses who ignore their customer base? They lose them. I hope you don't operate your own business with an attitude such as that.

<comment><USER8> no, free members are product, just like a farmer and a dairy cow, they have to do enough to keep you happy, but don't think for a minute you are their customer.

<comment><USER5> I don't care if I'm their customer. My point is that if they displease me, I'm leaving, and that does have an effect, same as if I was a customer.

If you want to look at it as they're losing inventory, fine. There's no difference.

</comment></comment></comment></comment></comment><comment><USER9> Personally, I don't buy the argument that this change is because Twitter wants users to use the official twitter clients.

<http://en.wikipedia.org/wiki/Hanlons_razor>

<comment><USER10> Twitter is retroactively changing the xAuth rules in a way that will break every existing install of a native client ( _except the official one_ ), and make every native client ( _except the official one_ ) going forward harder to use.

Stupidity would be breaking their own clients, too. Stupidity doesn't seem to adequately explain their commitment to going forward with this change, so we turn to Occam's Razor. The simplest apparent explanation for the observed behavior is that they want to discourage the use of third-party clients.

<comment><USER9> Maybe, but if I were twitter and wanted to discourage 3rd-party clients, changing authentication methods to one that is harder to use is a really roundabout way of accomplishing that goal.

</comment></comment></comment><comment><USER11> 7 steps* and a few hours to upload to the market.

in between you have 11 days to test.

* <http://donpark.org/blog/2009/01/24/android-client-side-oauth>

<comment><USER12> Those 11 days also need to include app store approval for iOS and getting all of your users to upgrade to the latest version.

<comment><USER11> it was a tongue-in-cheek statement about how nicer it is for the developer to have control of the publishing methods as in the android market opposed to iStore.

This time it was just a twitter-dick-move©, but tomorrow it could be a security vulnerability being exploited massively in the wild and you will not be able to provide a timely response.

i'm not saying that the android model is better. i'm all for no control. i'd ditch both if i could.

</comment></comment></comment><comment><USER13> I went back into history, to find my blog post about how to tweet from Python (<http://corbinsimpson.com/entry/the-bird-is-the-word>) and confirmed that Twitter started rolling out OAuth in July 2010. That means that they have given xAuth apps the better part of a year to transition, when the original plan was to give them only a month or so.

My sympathy is limited towards Twitter app developers -- you were warned a while ago, you've had plenty of time to figure out the new system, and it's really not that painful.

<comment><USER2> I think you are confused. Twitter had basic auth and they gave us transition period.

xAuth is OAuth but doesn't require a web based interaction to authorize. With xAuth, apps ask for a username and pass but get a token and only store the token (instead of storing the username and pass like with basic auth). This was created to help with UX of non-webapps like mobile and desktop. The first release of xAuth was Seesmic Look which was after basic auth was in the count to shutdown. xAuth is only given to apps that are approved by Twitter that prove that they are not a web service and need the improved UX.

The issue is that these apps are usually clients that desktop and mobile and probably need DM access, but xAuth clients can't ask for DM access (they are only allowing that access to clients that web auth).</comment></comment>


Astalavista Hack Act 2 - <AUTHOR> http://pastebin.com/m592e1f1c

<comment><USER2> >> // We at anti-sec, hope you never heal :]

I hope I'm not the only one who thinks that this is taking things too far. Compromising his server is one thing, compromising his health and delving into his personal life and exposing the details of others who have no relation to this little vendetta is another. Personally, I hope whoever is responsible gets caught.

<comment><USER3> Yeah I was coming to post the same thing. I "kind of" feel bad for this guy. Granted he might not be the most ethical of people, this might be going a little over the line. I wish I knew some back story as to why they are going after him other than just the fact that they run a crappy site (astalavista.com).

<comment><USER4> It might be because he has a script to mirror milw0rm - line 1387 states "If you by any means mirror milw0rm / exploits, you are a target and you _will_ be rm'd. only a matter of time."

Maybe not the primary reason, but probably a contributing one.

</comment></comment></comment><comment><USER5> Seems like people are discovering "hacklogs"; they're published in scene zines and are mostly harmful. The only reason to read them is for schadenfreude; it's usually one hacker taking out another, I don't think the misfortunes of civilians are logged.

For a glimpse into this, and for the most entertaining hacker interview ever conducted, I invite you all to read the phrack interview with The Unix Terrorist:

[http://phrack.org/issues.html?issue=65&id=2#article](http://phrack.org/issues.html?issue=65&id=2#article)

A magnificent display of ego, knowledge and balls. A laugh out loud tale of human malice! A+.

<comment><USER6> i dunno if the _only_ reason is for schadenfreude.

i mentioned it in the other thread, but i read them to see what other people are doing wrong in order to remind myself of what i need to do to do things right.

<comment><USER5> Hard to believe that. If you can grok the logs you probably know how and why the hack works. Plus they're not too informative, for example, few of them show the _version_ of an application under attack, and a good chunk of the time you will see a line like:

      ~ $./domagic
      ~ #

Where `domagic` is published script.

There are good texts to read for security, and _imo_ , lamer logs are not exactly at the top of that list. Read the public disclosures, advisories, PoC code; not the private gloating of hackers :-)

<comment><USER6> most aren't super informative, no. but some are. most i skim, some i read.

never said this was the only type of thing i read.

<comment><USER5> Let's not split hairs here. Of course you learn something from them, but be honest, aren't you smiling the whole time you read them? They're hacker tabloids; our version of seeing an actor in their fat, pale naked beach body.

I can't believe anybody would take a marker to a lamer log and "dive into it" looking for Knowledge(TM).

<comment><USER6> i don't take a marker to anything i find on HN, yet i still participate in the community and read the submissions in an effort to look for Knowledge(TM).

shrug.

</comment></comment></comment></comment></comment></comment><comment><USER7> "sh-3.1$ wget <http://anti.sec.labs/MichaelScofield>

That, ladies and gentlemen, to escape from a jailshell is just plain funny.

</comment><comment><AUTHOR> If anyone missed act 1: <http://news.ycombinator.com/item?id=642671>

</comment><comment><USER2> Response on reddit:

[http://www.reddit.com/r/programming/comments/8r04o/pwned_par...](http://www.reddit.com/r/programming/comments/8r04o/pwned_part_2/c0a5vu5)

<comment><USER8> Response has been deleted.

</comment></comment><comment><USER9> __According to__ nowayout, it is fake <http://pastebin.com/m1ddc62d7> ,

bot nobody cares/agrees to him on #bhf

plus its a nice read indeed, as twitter.com/linuxing said "its like geek porn..."

</comment><comment><USER10> While it sucks for the people involved, these posts just got me to go verify that all my sites have backups setup, and that the backups cannot be deleted via ftp

<comment><USER11> use scp instead.

<comment><USER10> The backups are encrypted with gpg before they are sent anyway, so it's not a big issue.

</comment></comment></comment><comment><USER9> The good part - we get a view of what one does when on gets into your box, this is good enough to build defense/alert systems against such activities...

<comment><USER12> There is not much to learn: 99% of the hacklog is looking around (ls, cat, mysql show tables ...), 1% is rm'ing and dropping database. Interesting things like vulnerabilities, exploit methods were done by some appear-out-of-thin-air magic scripts.

</comment></comment><comment><USER13> anyone got a dump? the pastebin entry was deleted

</comment><comment><USER11> Good fiction! I think some pieces could be inserted in some hi-tech serials and even books.

</comment><comment><USER14> anti-sec should do something about Mr. Ankit Fadia too, he is one jerk who would easily figure out in anti-sec's top 10 targets.</comment>


Nephtali: A simple PHP framework embracing functional programming principles - <AUTHOR> http://nephtaliproject.com/

<comment><USER2> Couldn't help but notice the irony of:

 _Nephtali's architecture revolves around the importance of properly validating input and escaping output._

and

 _Sorry, there is a big string escaping bug in Nephtali 3.3.0. Please update immediately to Nephtali 3.3.1._

Isn't there some Murphy's Law of software related to making claims about security?

</comment><comment><USER3> Nice initiative, but why try to hard to force a paradigm into a language that supports it badly?

</comment><comment><USER4> Surely there's a better way than using $name in every structure?

</comment><comment><USER5> I've seen many PHP frameworks, and this in anything but simple. Starting with something like Kohana requires almost no training, while this uses some really advanced PHP stuff, which means your junior and mid level programmers will spend a lot of time figuring it out and debugging silly typos.

<comment><USER6> There is a difference between simple and easy.</comment></comment>


Architecture's Modern Marvels - <AUTHOR> http://www.vanityfair.com/culture/features/2010/08/architecture-survey-list-201008

<comment><AUTHOR> The slideshow is here [http://www.vanityfair.com/culture/features/2010/08/architect...](http://www.vanityfair.com/culture/features/2010/08/architecture- survey-slideshow-201008)</comment>


Milk: Machine Learning Toolkit for Python - <AUTHOR> http://luispedro.org/software/milk

<comment><USER2> A new version was just released: <http://freshmeat.net/projects/milk/releases/329513>

(I'm the author of this package).

<comment><USER3> Could you please comment on why a Python machine learning developer should use your code and not, say, Shogun or scikits.learn? In what use cases would your code be preferable, or dispreferred?

How does your k-means implementation compare to that of scipy's?

Why not push your code as modules into scikits.learn? Their library is designed to be many loosely coupled components.

<comment><USER2> Why would you use my code instead of others? None of the packages covers all of machine learning, so it depends on what you're looking for. I focus mainly on supervised learning and kmeans. I want my algorithms to be as scalable as possible too.

Other projects have other priorities/functionality.

I like my interfaces better too, but I might be biased by being so much more familiar with them.

"""How does your k-means implementation compare to that of scipy's?"""

I think that my code is faster: <http://bit.ly/e8VOXy> and it is probably more scalable.

Scikits.learn has more functionality in certain aspects. So, if you need those, use it. I started milk when there was no scikits.learn. The interfaces are different and they work together here.

<comment><USER4> That's <http://packages.python.org/milk/benchmarks.html> if anyone was wondering

</comment></comment></comment></comment><comment><USER5> I've gotten so used to Github style pages that I expect to scroll down and see some examples, documentation and links. I actually found myself frustrated when I scrolled down to find nothing but a copyright notice. Even this site's github only had a changelog. Not a knock against the site, I just don't see much in the way of selling me on the library.

<comment><USER6> Here you go <http://packages.python.org/milk/> The link was right there at the bottom of the Github page. Some of the links from doc to the src code does not work though, but one can always browse the Github repository directly.

@luispedro I did not see your reply, hence the duplication. I see that Milk isnt doing too well on pca (11 times slower than the best performer). From the code it seems you are importing numpy.linalg. I think if you import scipy.linalg your results will be better without any change to the algorithm (unless you have built numpy with ATLAS or MKL).

Scipy.linalg links with underlying BLAS if its avaliable whereas the standard build of numpy implements linalg on its own (but it is possible to override that). Second point, I think for large data sets you are better of giving an api for computing an user specified number of principal components rather than all of them. Thirdly, if you find limiting yourself to gcc not too restrictive, you can stick with stl style algos in place of c++ looping. The advantage is that you will get parallelism for free [http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode...](http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html)

<comment><USER2> Yeah, I think we were writing at the same time.

Thanks for the tips. I know that the PCA implementation is very naïve, but I never put as much work into it as into some of the other parts of the library.

</comment></comment></comment><comment><USER7> How good would this be for computer vision applications?

</comment><comment><USER8> What is the advantage of this library over MDP? (<http://mdp- toolkit.sourceforge.net/index.html>)

<comment><USER9> Or,

\- Pybrain (<http://pybrain.org/>)

\- Theano/Pylearn (<http://deeplearning.net/software/pylearn/> / <http://deeplearning.net/software/theano/>)

\- Orange (<http://orange.biolab.si/>)

\- Pyevolve (<http://pyevolve.sourceforge.net/>)

There are many machine learning libraries for Python these days, all subtly different in which methods they support. I guess that's good :)</comment></comment>


Magic: The Gathering Is Turing Complete - <AUTHOR> https://arxiv.org/abs/1904.09828 <comment><AUTHOR> A note on this submission: This paper differs from previous "Magic is Turing- complete" links you may have seen here in that this construction embeds a universal Turing machine that runs _without_ requiring the players to make particular choices.

Note that the previous "Magic is Turing-complete" links you may have seen here were presumably pointing to the earlier constructions by Alex Churchill, which, as mentioned, required the players to make particular choices. Well, in this paper, Churchill (along with Biderman and Herrick) have finally gotten rid of the holes in the construction; once the machine starts running, the players have no more choices at all and cannot stop its operation.

So, now Magic is _actually_ proven to be Turing-complete, unlike Churchill's earlier constructions, which just showed it to be, uh, sort-of Turing- complete.

FWIW, the key innovation in this paper (compared to the earlier constructions) is the use of Wild Evocation, together with Wheel of Sun and Moon, to force Alice (player 1) to cast her cards in a specified sequence for the rest of the game. (Well, one of two specified sequences, as Coalition Victory is sometimes skipped due to Mesmeric Orb and Xathrid Necromancer, but that's details.)</comment>