De-Suckafying Apple's Butterfly Keyboard - <AUTHOR> http://sdbr.net/de-suckafying-apples-butterfly-keyboard/ <comment><USER2> I wish this was actually a fix for how shitty their keyboards are instead of what is essentially a fart app. I've taken my 2017 MBP in for three keyboard repairs at this point. Reluctantly spent $5k upgrading to this after the 2014 i7 air wasn't enough for development. It's easily the worst Macbook I've ever owned.

The kicker is that repair is no longer what I would consider "trivial", as to install a new keyboard yourself you have to gut the touchbar out of the old one because there's no way for users to pair a new one.

I also recently learned they killed Target Display Mode when they introduced the DCI P3 screens on both iMac and MBP. Perhaps the hardware to do so at that color depth wasn't available then and they couldn't justify doing it themselves, but it certainly is now. I doubt we'll see the feature return.

I miss when "Pro" meant actual professional level features

Edit: I should add I really don't mind typing on them, and can go just as fast as I can on my custom 60% with clears, the reliabilty is just ass for how much time I spend using it

<comment><USER3> > I wish this was actually a fix for how shitty their keyboards are instead of > what is essentially a fart app

Someone else has actually made a debouncing extension to avoid double-entry of keys with kind-of-sticky-but-not-yet-useless keys [https://github.com/aahung/Unshaky](https://github.com/aahung/Unshaky)

</comment></comment><comment><USER4> A year ago I excised MacBooks from my main computing life. An old System76 Galago Pro with a stand and a bluetooth keyboard became my couch computer, a Windows 10 with a Ubuntu VM for webdev Lenovo ThinkPad Yoga became my coffee shop / bar computer, and I turned my work MacBook Pro into a glorified desktop by adding an external display, keyboard, and mouse. Eventually I want to replace it with a Mac Mini but can't justify the expenditure this year. There's also an Arch Linux desktop that I'm typing this on now.

The only thing I use one for is at home in bed at 3am where f.lux Darkroom Mode on OSX is still unbeatable at what it does, and there's zero chance of liquid spills.

Apple's legendary quality just isn't there anymore, and the machines are so fragile to liquid damage and the repair experience went from awesome to utter shit over the last 5 or so years. I just can't justify it anymore. My next phone is a Librem 5, my next laptop a Librem 13. I love the OSX ecosystem but not enough to turn all my machines into hackintoshes.

I really didn't think it would only be a few years after Jobs died before Apple started whiffing. Now it's easy to see just how well he was able to keep the jackals away. Now the whole company is solely interested in making stupid amounts of money.

Such a shame.

</comment><comment><USER5> I've owned MBPs for over ten years. But my mid-2015 15" MBP ("peak MBP") is giving out, and I need a replacement. It won't be another MBP, because of the keyboard regressions -- the butterfly keyboard, and the touchbar. Thinking about a System 76 Galago.

<comment><USER6> I felt the same, but I went with a Surface Book 2 instead, I love this thing. Pretty sweet keyboard and I can get as Unix friendly as I need to with MobaXterm (use it for X forwarding) and WSL. I have an ASUS Laptop with Linux on it for my pure Linux itch and I still got a Macbook Air. I was ticket off that the Macbook came back and the Air looks more like a Macbook than the Macbook, they should swap names (I've said this too many times) between the products.

Anyway, I love my SB2, and my only regret is not being able to somehow know they were going to release it in Black a few months later. I await the SB3 and will buy it in Black if they offer it.

Another option for you might be Dell. The Dell XPS is a sweet looking laptop, I haven't had the pleasure yet though.

<comment><USER7> I've been looking at one of these and the only thing that worries me is the hinge - it looks like the laptop is "fat" at the hinge part instead of closing together snugly.

Is that a problem when carrying it around in comparison to a mac? Is it an annoyance?

<comment> apk-d I've been carrying around my SB2 15" in my backpack's laptop pocket for about half a year. Here's the summary.

\- Zero problem with the fatness on my end. Looks kinda sexy tbh.

\- The keyboard is really good about from the fn key which acts as a toggle (if you don't combo it with another key). Can never get quite used to that.

\- The body paint can get scratched and worn down if you're reckless.

\- The hinge itself works fine <comment>97% of the time. Occasionally gets stuck (can't detach) for unknown reason requiring a reboot or two, or some dirt gets in the way of the connectors and it thinks it got detached when you move it around.

\- Battery life _feels_ somewhat disappointing, but I haven't done rigorous tests. If you're planning to use the gpu, you better bring that charger.

\- The gpu gets thermally throttled pretty easily.

\- Performance at the 4k-ish resolution can be disappointing depending on the app (even the browser). This gets worse if you add an external monitor or if you don't run it above the "recommended" performance level. Unfortunately most devs (including MS) seem to optimize for 1920x1080.

\- My SB seems to have problems with WMR even with the official adapter (display goes black occasionally).

\- There's a driver (?) bug with the screen brightness sometimes being too low. I've filed a report on the feedback thing, but I'm not seeing or expecting any response. Love the screen (and the width\height ratio) otherwise.

Overall, it's a decent and interesting machine, but the edges can be rough.

</comment></comment></comment></comment></comment><comment><USER8> I see a lot of complaining about this keyboard online but I have yet to meet someone in person that thought it was as terrible as claimed. I love the new MacBook keyboards and Touch Bar but it's possible that I'm a complete outlier.

<comment><USER9> I wrote my Ph.D. dissertation on the 2016 MacBook Pro keyboard. It's... ok, I don't hate it, but even after years of using it, I still sometimes get this odd feeling that something is slightly off. I've _never_ had this feeling before, with any keyboard except possibly with some of the more aggressive ergonomic keyboards like the Kinesis (and that was more of a layout issue).

There are the maintenance issues, but that's not what I'm talking about here. I did have a sticky key (after about a year), and did get it fixed with Apple's free maintenance (edit: so I'm now on the 2018 keyboard), but this feeling I've had from the beginning and still do occasionally.

This contrasts in my mind very starkly with my experience with my very first MacBook keyboard circa 2009. I'd never had a Mac before or any kind of laptop, but when I first used the keyboard I never had to think twice about it. This stuck in my memory because of how much people raved about that keyboard at the time; but I guess it's a property of a good thing that you only notice it when it's gone.

<comment><USER10> When Apple replaces keyboards, they replace them with the 2018 keyboard (the one with the extra rubber barriers)?

<comment><USER11> No, they do not. Unfortunately, they are replacing them with the keyboard that your machine came with. Not the 2018 ones that have sort-of fixed the biggest issues.

<comment><USER12> My question is, after 3 keyboard replacements will the Apple Store simply hand you a new/refurb MBP of similar specs?

</comment></comment></comment></comment></comment><comment><USER13> There are many complaints about the MBP keyboard. I don't know whether "not noisy enough" is one of them.

<comment><USER14> The next version of this app will prevent microscopic dust particles from blocking/repeating keystrokes

</comment></comment><comment><USER15> Last year I drank the cool aid and bought a mechanical keyboard.

I don't get it. Compared to butterfly they are pretty bad.

Extremely long key travel is supposed to be save me from carpal tunnel. I find it quite exhausting. More worrying is the tactile feedback. When a butterfly (or any other chiclet keyboard) clicks, it registers.

Not so much on a mechanical, not even the tactile. It is worst on the linear gaming keyboards, where resting your fingers on the keys can cause them to register. Normal linear keyboards do need to sink deeper before registering, but again, there is absolutely no feedback.

The tactile keyboards have a "click" somewhere, but it is not connected to the actual keypress registraion.

On top of that they are ridiculously tall.

Like most people I prefer thinkpad or old mac keyboards over the butterfly keys, but they are pretty fine, and I would call them very tactile, but I guess that is going to rub a lot of people the wrong way. So maybe I just go with calling them very responsive, with a high correlation between the audible and felt click and key registration.

<comment><USER16> Unfortunately, you fell for the myth.

Mechanical keyboards might just be _worse_ for RSI etc, because it's hard to rid yourself of the habit of pounding on the keys to bottom them out, which one has to do on a membrane keyboard. Most mechanical (certainly most Cherry) switches actuate before bottoming out, and through some mindfulness, it _is_ possible to train yourself to type sedately, without bottoming out. But it's hard, and not possible to do _all_ the time. The long keytravel is also a literal pain.

The only reason to have a mechanical keyboard is enjoying the key feel, and noise. Typing at the speed of light is way more enjoyable on a keyboard that clacks along happily as you type your tome. If a membrane keyboard does it for you, all the better. Save yourself $$$ on the expensive keyboards and (worse still) expensive keycaps.

</comment></comment><comment><USER17> Trying this out. I like it more than I thought I would. But a couple comments:

1) The sounds appear to all be the same, regardless of key. Seems there should be some subtle variation in the sound, even if it just a very slight modulation in pitch? This would better map with real mechanical keyboards.

2) The sounds appear too far delayed to me. Like it's slightly out of sync w/ my typing. I turned off the keyup sound—which helps—but not enough. It may be this is a limitation you can't overcome.

3) The sound quality seems low. Maybe obtain higher quality samples and/or don't compress it so much?

<comment><USER18> I'm using it right now—it seems like keys towards the right get put more on the right channel of audio and the ones on the left more on the left, which is a nice feature.

I think some subtle variation (like, adding an effect randomly or having ~10 recordings) could make this even better.

</comment></comment><comment><USER19> This is cool (and I don't even use mechanical keyboards). It reminds me of the movie "The Dilemma" where the characters were making an audio system to emit fake "muscle car" engine sounds for electric vehicles.

Not a great quality clip, but here is the scene: [https://youtu.be/Etu44hXY3zg?t=55](https://youtu.be/Etu44hXY3zg?t=55)

<comment><USER20> Some luxury cars play engine noise through the speakers:

[https://www.caranddriver.com/features/a15117726/faking-it- en...](https://www.caranddriver.com/features/a15117726/faking-it-engine-sound- enhancement-explained-tech-dept/)

<comment> munk-a Reading through that it looks like sometimes the sound is directed inward at the cabin and other times the speaker is in the engine itself... that latter setup is just so considerate to us pedestrians who love to hear people tear their engines out on short downtown blocks - thanks VW! /s

<comment><USER21> I worked with a company that conducted some of the research that led to this - a major problem with electric cars at the moment is that pedestrians use the sound of cars to a) register them in the first place and b) judge when the car will arrive (speed).

If a conventional vehicle is coming around a corner you can hear it, anticipate its imminent arrival and act accordingly (especially important on country roads without a pedestrian sidewalk) whereas with an electric car the pedestrian receives no such audible warning. So yes, the engine noise is a consideration specifically for pedestrians.

</comment></comment></comment></comment><comment><USER22> Another better(battery life maybe) one in rust, [https://github.com/yingDev/Tickeys](https://github.com/yingDev/Tickeys)

</comment><comment><USER23> Relevant: [https://github.com/rbanffy/selectric- mode](https://github.com/rbanffy/selectric-mode)

</comment><comment><USER24> Tried it out, and while fun, there was just too much latency for me to enjoy the clickiness. It felt like I was mildly drunk while using it.

</comment><comment><USER25> I solved this by just setting up a magic keyboard/trackpad at work and home. I'm happy with the MBP keyboard but I have issues with debris sticking in keys. This way I can still be a slob, but keep the actual laptop keyboard clean.</comment>


Ask HN: Best places to learn what school doesn't teach you? - <AUTHOR> <comment><USER2> Life.

It may be a general answer, but school is only a small part of life and your course of study only covers a fraction of a percent of the knowledge that exists in the world. Even look at how many courses you take divided by how many courses a university offers.

The best thing I can recommend is to research things you come across that you are interested in and could be practical.

If you are looking for suggestions:

\- Financial basics like time-value-of-money (inflation, interest, etc), opportunity cost, investment vehicles (bank account, CD, stocks, bonds, options, etc)

\- Mechanical skills such as changing a car's oil, fix a leaky faucet, replace a toilet, etc. This is stuff that you can look up when the need arises. The point here is not to write yourself off before trying. Start with small projects.</comment>


The Problem with Threads (2006) [pdf] - <AUTHOR> https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf <comment><USER2> Another threads post another opportunity to discuss what I learned building a joint (on the same memory) parallel app. server: [http://github.com/tinspin/rupy](http://github.com/tinspin/rupy)

To fully use concurrency without monitors I think we need to accept the cost of cache misses. When Java rewrote the memory model of the JVM to allow for concurrent data structures they did something C/C++ still has not provided: a platform where you actually can build something that scales on many threads without causing more problems than it solves.

To me this has divided the programming word into two: Avoid cache misses or use many threads. Pick one?!

<comment><USER3> Well, no, we don't need to accept that cost, it's just a constraint for a concurrency model to choose, i.e. _maximizing locality_. Apart from that another big one for massively multicore systems is _minimizing cross-core synchronization_. You can meet both, just not with threads as your programming model.

<comment><USER2> So what would you use instead of threads?

How do you mean "maximizing locality"?

My intuition is that the reason Java can be concurrent is that it uses a VM that incurs cache misses on all IO. So in practice you can't have both.

In C you can try to use locks to achieve something but for a long time of development you will be in dead-lock and race condition hell.</comment></comment></comment>


Google Takes on Cable with 'YouTube TV'–40 Channels for $35 - <AUTHOR> https://www.wired.com/2017/02/youtube-tv-skinny-bundle/ <comment><USER2> I am disappointed in that it appears to have the same trap as cable, forced ESPN. So how ESPN tax is this setup? The channels look interesting but the price is just to high.

Leaving cable is getting to be more expensive than having cable once you start putting back all the channels. When calculating the cost of replacing cable TV add in a portion of what you are paying for your internet.

A better solution is to have different monthly fees and you get certain number of points to spend on channels you like and each channel shows how much it cost. Then its truly worth my while. I know its not going to happen but there are too many providers for each to charge separate fees.</comment>


Autism clusters found in California, linked to highly educated parents - <AUTHOR> http://www.environmentalhealthnews.org/ehs/news/autism-clusters <comment><USER2> Very similar article posted earlier: <http://news.ycombinator.com/item?id=1035155></comment>


Chessvision.ai – Analyze chess position from websites, images or video - <AUTHOR> https://chessvision.ai/ <comment><USER2> Hi, many thanks to innerspirit for posting this! I'm the author of the app and you can find discussions about it on reddit as well:

r/MachineLearning :[https://www.reddit.com/r/MachineLearning/comments/b8jdho/p_d...](https://www.reddit.com/r/MachineLearning/comments/b8jdho/p_detect_and_analyze_chess_positions_with_ai_from/)

r/chess: [https://www.reddit.com/r/chess/comments/b826h5/created_chess...](https://www.reddit.com/r/chess/comments/b826h5/created_chessvisionai_a_computer_visionmachine/)

If you have any opinions and suggestions I'd love to hear them!

<comment><USER3> Very cool! This'd be absolutely great for getting more value / use out of the pile of Everyman books that I [and, I'd hazard a guess, a solid chunk of chessplayers in general] have sitting on the shelf that don't get used as much as they should

<comment><USER4> What are the best three books for beginners?

<comment><USER3> Great question! There are lots of great beginner books out there, but if I had to pick three:

1) "A First Book of Morphy" by del Rosario -- takes the very well-considered principles of GM Reuben Fine and illustrates them with [mostly] Paul Morphy's games. Of all the books I've ingested on the subject of chess, this one has stuck with me most. Even my kid loves it!

2) "Winning Chess Strategy for Kids" by Coakley -- it's not just for kids! And it's not just strategy! Covers fundamental tactical concerns such as pins, forks, etc in a straightforward way. Similar in some regards to Pandolfini's "Weapons of Chess" but pedagogically superior in my view.

3) "Silman's Complete Endgame Course" by Silman -- the old saw that one should study the endgame _first_ is pretty true -- Silman is the best at teaching it -- man, if I had a dollar for every game I was winning in the middlegame and then lost in the endgame, I'd have... well, a lot of dollars

cheater extra: 3.5) "Bobby Fischer Teaches Chess" \-- the old standby -- this is a tactics book first and foremost, and the main value of it is that it gives you puzzles of gradually increasing complexity so that you can really feel your comprehension improving and say to your self, "I'm getting it!" Truth is that getting discouraged is the thing that stalls or scares off many / most novice chessplayers

When you start getting up in the 1100-1300 range, pick up "My System" by Nimzowitsch and "How to Reassess your Chess" by Silman, "Soviet Middlegame Technique" by Romanovsky -- and after then, start learning openings in more detail. The biggest mistake most beginners make, including me, is building up a repertoire of openings before having a solid grasp of the fundamentals. Truth is, below 1300, most players are "off book" by the ~tenth move anyway, so learning the intricacies of the Nimzo-Indian isn't gonna do a person much good at that stage.

<comment><USER4> Thanks a lot. Appreciated.

</comment></comment></comment></comment></comment><comment><USER5> It'd be great to convert this into a mobile app that lets you take a photo and then loads it into a game analysis board. We would use this all the time at my local chess club. Sometimes we just want to know what the best move is and other times we want to save the game so we can continue it later.

I would pay $10 or $1.99 a month for this.

Food for thought!

<comment><USER6> This would be much much harder with a real board with 3D pieces.

<comment><USER5> I see. Well, one thing that may help is that 95% of chessboards (at least at the clubs I've visited) use the same piece set: [https://www.amazon.com/WE- Games-Complete-Tournament-Chess/dp...](https://www.amazon.com/WE-Games- Complete-Tournament- Chess/dp/B000JMCLME/ref=sr_1_4?keywords=scholastic+chess+board&qid=1554314003&s=gateway&sr=8-4)

Also, a 10% error rate wouldn't be a big deal as long as it was easy to correct the position within a few seconds.

<comment><USER6> That makes it vaguely possible yeah but going from a flat on 2D grid to a 3D set of pieces at an angle is a whole different set of problems.

<comment><USER7> I wonder how much easier it would be if you narrow down the likely set of pieces for each square. There are obviously some positions for some pieces that are invalid (bishop on the wrong colored square), but there are probably a lot of other positions that are so uncommon that they could be discounted.

<comment><USER8> What would make it easier IMHO is to make it a top-down version only. Take a photo from the top, then the program breaks down the board into 8x8 squares, feeds each square into a classification algorithm that you will train on a bunch of hand labeled images. Fine tune the model as you gather more data.

<comment><USER9> The pieces look more similar from the top, though. With bad enough contrast everything is just a circle. So you need some kind of angle.

<comment><USER10> > With bad enough contrast everything is just a circle.

Yes but does real world photos ever have that poor contrast? IMO, top down photo is worth exploring.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Just to clarify an important detail that pkacprzak (the author) has been asked many times now by the streamers he is using the images of (GoldDustTori and GM Ben Finegold) - NONE of the streamers actually used this app during a game, as that would be considered outside assistance and cheating. The app is intended for viewers to follow along, not to enable cheating (even though the cheaters will use it for that purpose).

</comment><comment><USER12> One feature that would be useful for me would be the ability to convert a video to a PGN of the game. This could, for example, be used to strip game data from streamed chess en masse and then analyze the chess games in aggregate.

</comment><comment><USER13> I thought they meant like in vivo in 3D, such as the scene in Independence Day

<comment><USER14> That would rock for chess tournaments. Webcam next to the board and run analysis for the audience...

<comment><USER15> Hey! I'm working on exactly this same problem for an undergraduate Computer Vision course right now. It's not going well! Chess piece recognition is hard. I definitely think the electronics approach described in the other comment is a much more reliable way to go.

<comment><USER16> Sounds like a blast!

Are you restricted to to a single game piece set?

This might be hugely easier if you can keep state between turn analyses. IE, if a white rook disappears from A5 and some unidentified white piece appears at C5, then it's probably the rook.

<comment><USER17> We weren't given many constraints related to the chess piece recognition itself. The course instead asks us to implement a CV research paper, and we chose an existing research project which focused on chess piece recognition.

That lack of constraints led us into running face first into issues of generalisation and variability within datasets. As in, exactly what you allude to with limiting the piece sets.

I think in my undergraduate naivety my aspirations were too high with what could reasonably be accomplished. I've spent a lot of time trying to improve an aspect of the project that really didn't need to be improved, which prevented meaningful progress.

Now finals are coming up and I feel terribly stressed. Having trouble functioning. Brain fog, etc. I feel so sad right now.

EDIT: I keep forgetting my password so apparently I have multiple throwaway now. Sorry.

</comment></comment></comment></comment></comment><comment><USER18> Pretty sure this will be (ab-)used for cheating in online-chess.

<comment><USER19> Isn't it much easier to run the moves yourself on another board with computer help?

<comment><USER20> not if you're playing bullet!

</comment></comment></comment><comment><USER21> Maybe it's just me, but I'd be wary of any browser extension that captures and analyzes my screen over-the-wire, especially if it is closed-source like this one.

Not to say that this is necessarily malicious. But I personally wouldn't recommend this to anybody as of right now, unless you want to risk leaking potentially sensitive data to a third-party.

</comment><comment><USER22> Small typo on the front page: "Postition From a Video" -> "Position From a Video"

<comment><USER2> Thanks a lot, I fixed the typo

</comment></comment><comment><USER23> Should have called it CheckMate!

</comment><comment><USER24> Seems cool. Does it use a server or it does all the calculations in the browser?

<comment><USER2> Server side

<comment><USER25> This is kind of a bummer for privacy reasons. Sending your application screenshots of my browser feels not-great.

To be honest, I trust you, even as a random stranger on hacker news. But I don't trust that you'll never sell this, and I don't trust whoever you you might sell it to.

<comment><USER2> I understand your concerns and would like to clarify any potential doubts. The client app (the extension itself) has only currentTab permission which means that it has access only the tab where user opened the extension and it takes a screenshot only when a user explicitly clicks Scan button. The source code of the extension is completely public - everyone can unpack it and verify that indeed it does exactly that. So this actually reduces to the same functionality as for example using any photo app with cloud processing - i.e. you take the photo/screenshot explicitly and no other information is sent to the server.</comment></comment></comment></comment>


Adobe Donates Flex to Apache - <AUTHOR> http://www.pcworld.com/businesscenter/article/244060/adobe_donates_flex_to_apache.html <comment><USER3> The real challenge is with enterprise applications that need a rich UI - <USER2> is where Flex was a good solution. Saying "just use HTML5" is fine when you serve the consumer space; it's not if you serve enterprises.

HTML5 is just not a go-er for enterprise products that need a rich UI. Even if it could do everything Flex can (and it can't, yet), you need a modern browser. Many enterprises still use IE6. I'd say 60% of our customers are on IE6; and the remaining 40% use IE7. Demanding IE9 would make an enterprise product dead in the water.

Flex fitted here. You have enterprises who say "no more client server, everything should be web" but then don't give you the web platform to be able to deliver the required user experience (i.e. you must use IE6/7). Flex let you deliver on the web, with a rich UI, on legacy browsers.

So you had a choice:

\- Stay on client/server (lots of enterprises won't consider you)

\- Develop for HTML5 (not quite prime time, no-one can buy your product as won't work on their browsers)

\- Dumb down the UI and deliver in IE6 (workable for some projects, but not for many - some products really do need a rich UI. Especially not doable when porting existing rich client/server app to being webbased - clients don't like backwards steps on the UI)

\- Develop in Flex

So it's all well and good saying people yelled 'iceberg' but really you're between a rock and a hard place, and even with this news I'm sure most Flex enterprise developers would make the same decision again - because there really weren't many alternatives.

<comment><USER4> """The real challenge is with enterprise applications that need a rich UI - this is where Flex was a good solution. Saying "just use HTML5" is fine when you serve the consumer space; it's not if you serve enterprises."""

I don't think there is anything that can't be done with HTML5 (the whole stack, I mean), nowadays, and that Flex can do it. Especially since an enterprise can dictate to it's users to use a capable modern browser.

There's plenty a full native solution can do that HTML5, but Flex ain't that, and besides being limited it's also not that rich component-wise anyway.

<comment><USER5> I don't think you've got the point- an enterprise _can_ dictate to it's users to use a capable modern browser, but they won't. Mostly because they have other legacy software which requires an old version of IE.

Or because they're lazy, but they don't like being confronted with the product of their laziness, so if you tell them to upgrade their browsers then they will go to a different company that'll use something like Flex.

<comment><USER6> Chrome Frame nicely addresses all of these concerns

</comment></comment></comment></comment><comment><USER7> If they'd done this 3 years ago and focused on building kick-ass Flex development environments/authoring tools/etc, Flex would actually have been worth donating at that point. Right now, this feels more like "Here's this cat, I've had it for 10 years and I think it's dying (probably because it was just run over). Take good care of it, thanks."

<comment><USER8> I'd say it's more like: "HTML is getting closer to what is possible with Flex, so we have to concentrate on that. Flex will thrive as much as the community wants it to. If the community wants it, it will develop it further, if not - why should we?"

<comment><USER9> It's probably more fair to say that the HTML spec is getting closer to what is possible with Flex. Browser support is a whole different issue.

</comment></comment></comment><comment><USER10> Someone at twitter ..

Dumping projects to the Apache F. is the new convenient way to abandon projects while saying "look, it's a good thing!"

<comment><USER11> Yes, once they decided to refocus on html 5 it would have been a whole lot better for them to just dump flex and leave all its users without any support whatsoever, especially since the apache fundation is forced to accept to take charge of such projects even if they don't want to.

Mocking is easy, given the alternatives this is a quite a decent outcome.

<comment><USER12> > especially since the apache fundation is forced to accept to take charge of > such projects even if they don't want to.

No, it isn't. Nothing says they (we) have to accept anything.

<comment><USER13> We have a difficult time saying NO.

Right now, Adobe has not even submitted a proposal to the incubator -- just blog posts about how they intend to submit it.

I eagerly await their submission of a Flex proposal. Part of the proposal, and critical for Flex, is proving this isn't just a code dump. If it is a code dump, I will vote -1, and I hope everyone else does too.

<comment><USER14> What additional things would make the difference?

</comment></comment></comment></comment></comment><comment><USER15> Many enterprise projects have invested big time in Flex. Now Adobe has basically said "We are pulling out most of our full time resources and _hoping_ that the ASF picks up the slack. HTML5 is the new hotness so move to it"

This basically sucks for a lot of enterprises because like it or not : 1) HTML 5 is still evolving and maturing 2) Flex capabilities today are where HTML 5 will be in 1-2 years.

It feels like adobe could have managed this situation a lot better. Slowed down Flex dev a little and accelerate HTML5 a lot. Provide kick-ass tools for converting between the two (ala Google Swiffy but something that works much better). Publish detailed guides on how to migrate - what works and what doesn't with the migration, etc. Basically make the people who adopted your tech feel that they are NOT being left high and dry.

<comment><USER16> Sorry, stupidity has a price. People yelled "iceberg" and explained the issues with Flash a couple of years ago. Now you've hit the iceberg. Read and try to digest:

<http://www.apple.com/hotnews/thoughts-on-flash/>

Yes, a very un-HN answer but I still see people stuck in IE6 because I couldn't convince corporate lemmings that web software needed to run in browsers other than IE6.

The web needs to run everywhere! It's not owned by one company.

<comment><USER17> Last I checked, the warnings about Flex were few and far between, and Flash is still very much alive and well. This is not the iceberg you are looking for.

<comment><USER6> I've seen plenty of people point to the single-source vendor as a major concern. Given Adobe's failure to competitively maintain any platform they've acquired most people I know were careful not to put too much trust in something which could be discontinued at any point.

</comment></comment></comment></comment><comment><USER18> Do software companies get tax writeoffs for donating software projects in which they've incurred significant development expenses?

<comment><USER19> I imagine they would if the project itself is still worth something and they are donating to a non-profit.

<comment><USER20> A more interesting question would be how do you evaluate how much you get to write off you taxes? Adobe is donating presumably because they believe the current value of it is low, but just as easily they could argue that as a mature platform it is worth hundreds of millions.

</comment></comment></comment><comment><USER21> There is a lot of talk about the consequences for Flash of these recent announcements, but little attention is given to what this will mean for HTML5 adoption.

I, for one, am very excited. If Adobe can do for HTML5 half of what they have done with the Flash toolchain then we are going to see a powerful platform indeed, and sooner than anyone would have dared hope until recently.

A Flash-like animation environment and a Flex UI toolkit, all outputting to canvas? Sign me the hell up right now.

</comment><comment><USER22> Adobe should have done this before the negative news (them announcing that flash on mobile is not going to be supported).

<comment><USER23> I do not agree. I believe they did the right thing, now Apache has everything they need to take their decision. That Flex will be less and less supported by Adobe in the years/months to come so they'll probably need to put more resources on the project.

Doing it before would have been wrong and not well received by anyone.

<comment><USER22> My point was that I believe that Flex would have built a larger community of supporters had they open sourced it first.

</comment></comment></comment><comment><USER16> This does guarantee that the tools will live on. Adobe has already moved many resources to their Html5 tools. They are taking a lot of heat now but they are focusing on a much larger market and it will look like a great move in 3 years.

</comment><comment> johnx123-up I'm now worried about the _future_ of Apache... Will all abandoned projects go there?

<comment><USER24> I don't get this complaint. That's part of the awesomeness that comes with open-source.

Dying projects can be brought to life if you find a usage for them. For example, Blender (<http://www.blender.org>) was dumped by a dying company and brought to life again by enthusiasts.

Why? Because they could. Projects, even when abandoned, are still valuable.

Now, the real problem with Flex and the reason why Flex will probably die is not abandonment. Flex may die because it sits on top of a proprietary plugin. That's the real jewel that should be open-sourced before it is too late.

And yet another reason why people may not be interested in an open-sourced Flex ... Flex has competition that can compile to Flash AND Javascript: <http://openlaszlo.org/>

<comment><USER25> You do realize that Flex already _is_ open source?[1]

About OpenLaszlo... I thought that it could become important one day; however, this never happened. I haven't looked into OL for quite some time now, but what can it offer that you can't get with HTML 5 nowadays?

[1] <http://opensource.adobe.com/wiki/display/flexsdk/Legal+Stuff>

</comment></comment></comment><comment><USER26> Read: Adobe abandons flex

<comment><USER27> Hi, I work for Adobe as a Flex expert, and here's my point of view. Well, actually I think that first Adobe needed to start with a "product" strategy. Flex was the first RIA technology, and it's still the leading RIA technology of the market. Adobe had to innovate, experimenting new features every year and getting the community excited. That's what generates adoption. Now that the Flex SDK is very mature, it can answer almost all Enterprise needs. It's time to let the community and the customers drive the decisions with Adobe about the future of Flex. Flex masters want to actively contribute to the framework for years. Now there is an opportunity to install Flex as a standard Enteprise RIA stack. Adobe is not only proposing Flex to Apache, Adobe is also proposing BlazeDS, Falcon, FalconJS, and will share all the work already done on Flex 5 components. Details are here: [http://www.adobe.com/devnet/flex/articles/flex- announcements...](http://www.adobe.com/devnet/flex/articles/flex- announcements.html)

<comment><USER28> More of a worry is the fact Flex is dependent on the Flash player which as of yet has not been opensourced.

A headless player is holding back CI in a big way.

I also can't see FalconJS delivering a full flex stack without help from the browsers. A lot could be rendered in a canvas, but then you get into situations where you need stage text etc...

I just wish Adobe had a simular JS environment to announce at the same time, or slightly before. At least then there would be a migration path. Currently Flex devs are trying to find a simular enterprise RIA platform, and none of them are owned by Adobe.

<comment><USER29> Flex has a dependency on the Flash player, but that doesn't have to be the case. As an ASF project, that dependency can (and likely will need to be) broken.

</comment></comment></comment></comment><comment><USER30> But is there enough incentive to make Apache, jump on it ?</comment>


Recreating the Aroma of the Ancient City: Incense in the Ancient Mediterranean - <AUTHOR> https://www.forbes.com/sites/drsarahbond/2017/06/26/recreating-the-aroma-of-the-ancient-city-incense-and-perfume-in-the-ancient-mediterranean/#3c569e30586a <comment><USER2> Nothing changes. I'm sure the ancient world had the equivalent of Scentsy hawkers. My wife has an essential oils kit and vaporizer. Of course it is sold like Tupperware.

<comment><USER3> I'm sure it was much more important in a world without ubiquitous running water.</comment></comment>


Fearsquare : see the official crime stats for the places where you 'check-in' - <AUTHOR> http://fearsquare.com/ <comment><USER2> UK only.</comment>


How many dots can you see?Optical illusion in 18 lines of pure JavaScript - <AUTHOR> http://slicker.me/javascript/illusion.htm <comment><USER2> it's Yanni!</comment>


Explosions in Brussels Kill at Least 13 - <AUTHOR> http://www.nytimes.com/2016/03/23/world/europe/brussels-airport-explosions.html?hp&action=click&pgtype=Homepage&clickSource=story-heading&module=span-ab-top-region&region=top-news&WT.nav=top-news&_r=0 <comment><USER2> It's horrible, as a french here, my thoughts are with my fellow Belgian friends.

</comment><comment><USER3> This news is everywhere. We simply don't need it reported on HN.

<comment><USER4> HN isn't only about reporting, but about discussing, no?

<comment><USER5> "Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off- topic."

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment><comment><USER6> Terrorists must have been really pissed off by Apple's yesterday annoucements.</comment>


Brackets editor 1.2 released - <AUTHOR> https://github.com/adobe/brackets/wiki/Release-Notes:-1.2 <comment><USER2> Sublime Vs Atom Vs Brackets...which are best in what...??...Recently switched to Atom from Sublime ..and quiet happy with the speed and updates...

<comment><USER3> The answer is vim. Don't be scared of it, just dive in and you'll never want anything else again.

<comment><USER4> My experience has been the opposite. I've made a number of good efforts to get moving in vim, and for anything other than basic text editing I find it a pain to use. I currently really like Light Table, though it's got a ways to go before it'll be my daily.

</comment></comment></comment><comment><USER5> I tried Brackets once, but it was really web developer oriented from the start. I went full Atom a couple weeks ago and I love everything about it except its opening speed. It just took 9 seconds to open on my iMac and I haven't installed any plugins really. Sublime opens instantly. Really hoping the Atom devs can speed that up...

<comment><AUTHOR> I keep trying Atom, but performance is killing it. Especially multiple cursor support. If you try changing a token that appears several hundred times, pretty much impossible.

In brackets, it is painfully useable doing the same, but in sublime you can't even tell you are editing hundreds of lines, it is just as fast as editing a single line.

Javascript is now fast enough, but the DOM seems to be the roadblock. I'm hoping one of these editors will finally make an innovative leap like react- native did on mobile but on the desktop. Skip the DOM and use canvas or native widgets. We should then have something mostly on par with other editors in terms of performance.

<comment><USER6> Atom just had an update this week that's supposed to have improved the DOM interaction. It might be a bit better now.

Out of curiosity, what's your use case for changing a token that appears several hundred times with multiple cursors? Wouldn't find and replace be more effective?

</comment></comment></comment><comment><USER7> Maybe I give Brackets another go since its been a while...

However what I really want: AST driven auto-complete VS-style for coffee/coco/livescript. This will probably not happen in an editor written in JS... at least it will not be that pleasant.

<comment><USER8> Why not, JavaScript might not be the best match for something like this, but its better than emacs lisp in terms of performance and several emacs modes support this.

</comment></comment><comment><USER9> didn't realize they use jquery. why?

</comment><comment><USER10> This, still a thing?</comment>


With No Frills or Tuition, a College Draws Notice - <AUTHOR> http://www.nytimes.com/2008/07/21/education/21endowments.html?em&ex=1216872000&en=fa7413adb3d96c53&ei=5070 <comment><USER2> I went to Berea for my undergraduate degree.

My first two semesters I worked 10hrs/week in the pit (the basement of food services) on weekends at 6am cleaning dishes. Not that fun.

Each semester after that I would work in either multi-media production or as the only student assistant systems analyst. This meant converting cobol applications running on a Prime mini-computer to Oracle Forms.

They didn't have a computer science major at the time, so I majored in mathematics (and loved learning about proving things and that advanced mathematics != calculus). While they do have computer science now, I would highly recommend doing self learning (lisp, python, javascript, ...) and majoring in math, science or even theater!

</comment><comment><USER3> For those interested in a tuition-free, high-quality engineering college, consider Olin College.

I didn't go there, and I have the student loans to prove it.

<comment><USER4> Olin's in my neck of the woods (literally) and I have a friend that's going there. A good school, a great price (only pay room/board.)

</comment></comment><comment><USER5> Getting Real for universities?

<comment><USER6> A lot of them could use a little dose of reality.

But if the textbook manufacturers don't also get a dose of it (or a swift kick in the teeth, I'm flexible on the matter), it won't solve the entirety of the problem. A few years ago, my girlfriend paid nearly $400 for a single book/CD- ROM/online combo for _one class_ \--and the CD-ROM/online service was licensed to disallow resale. That was the most expensive, but many classes require three or four texts at $100+ each. So, even if the schools themselves lower admissions dramatically, there's still a huge swath of costs that lower income folks won't be able to manage. It just seems like the textbook industry has gone mad with power and greed...I managed to make it through school with almost entirely used books from alternate sources (usually prior editions, even, which could be had for pennies on the dollar from local used bookstores), but the textbook manufacturers seem to be figuring out ways to prevent that--more frequent new editions, more dramatic changes between editions to make it harder for students to find their way in older editions, and the associated media licensing tricks to prevent legal used sales entirely.

<comment><USER7> I would order the "restricted asian edition" textbooks on-line for about a quarter of the normal price. The quality is not as good, but the content is certainly there. I never exactly understood the legality of doing this, but it's certainly a testament to the growing problem that is the college textbooks market.

<comment><USER8> When I was in school, we'd always order from Amazon.co.uk because European countries apparently subsidize textbooks, and so we could get them for about 1/3 of the U.S. price. Unfortunately the falling USD has kinda nixed that practice, and I think Amazon may've started adding shipping surcharges for ordering from Amazon.co.uk and shipping to the U.S.</comment></comment></comment></comment>


San Francisco to robots: Don't crowd our sidewalks - <AUTHOR> http://www.sfchronicle.com/news/article/San-Francisco-to-robots-Don-t-crowd-our-12411062.php <comment><USER2> If this policy is based on fear of automation (and I sense that this is the case), it is totally misplaced.

Impending paradigm shifts are best adopted early and surmounted immediately, rather than waiting for someone else to reap the first fruit. Doing otherwise is equivalent to putting one's own head in the sand.

<comment><USER3> What if it's based on preference to pedestrian traffic? As I'm reading this, I'm imagining a future where these robots clutter the sidewalks. A shame, since my community has worked so hard to encourage walking and mass transit over cars.</comment></comment>


Tinholes – performant, strongly typed lenses in Clojure - <AUTHOR> http://blog.podsnap.com/tinhole.html <comment><USER2> This is exciting. Lenses are really powerful and ought to be used in more languages to accompany immutable data types. It'd be nice to see if this technique can generalize to traversals and prisms as well. In practice, I use those two in nearly any lensy computation.

Using macros to pre-compile the lenses is clever, but feels like a hack around typed-clojure instead of being aligned to it. All of the information needed to determine a lens' action is available at compile time even prior to expansion. Can a van Laarhoven representation be made in typed-clojure that recovers this information?

> _type-safe, efficient, concise, idiomatic and flexible handling of deeply > nested data structures, and that 's what we got. Prima facie, these were > unreasonable requests - it's not as though other languages were lining up to > answer them_

and since the line was crossed: yes, other languages are exactly lining up to answer all of those. You don't even have to burn-in the choice of lens. It's exciting to see this technology developing all around, but it'd also be nice to see it with a bit more humility.

<comment><USER3> I apologize for my miscommunication and ignorance. First, the bragging was supposed to be on behalf of the Clojure ecosystem rather than myself. Second, while I am aware of the standard lens implementations in Haskell and Scalaz, I didn't see that either dealt nicely with intra-path transformations, and the Scalaz version didn't seem very concise. If there are more examples, or if I'm wrong about these, I would love to learn more. I agree that the interaction with typed Clojure is not ideal, but at least there's an interaction of some sort, albeit possibly a "hack." Googling "van Laarhoven" has led me to a few hours of reading material and to SPJ's talk, so thanks for that...

<comment><USER2> Could you demonstrate a simple example of the intra-path transformation? I am not sure that I see exactly how it should be implemented, but so long as it isn't a lens law violation I think you can do it in Haskell's lens system at least.

<comment><USER3> I was thinking of setting ```:c``` in ```{:a {:b "{:c 5}"}}```. More generally, a leaf in the container tree that is not itself a container but can be converted to and from one. I need to play more with [http://hackage.haskell.org/package/lens](http://hackage.haskell.org/package/lens), but I'd certainly appreciate a shortcut to enlightenment...

<comment><USER2> So there are a few things going on here

        1. Focusing on "the subtree" instead of "the value
           at the subtree"
        2. Working with data types like `{:a {:b {:c 5}}}` is
           somewhat uncommon in Haskell (too little information
           gets projected into the types)
        3. Doing "along the way parsing"

Each of those are fine to do in Haskell and I could work up an example. Perhaps the best domain for this is using the lens-aeson[0] package since your data type is not so different from JSON. Here you can use the _JSON prism to do your "along the way parsing" (the failure mechanism of prisms catches failed parses naturally). You can also focus on whole subtrees naturally (since the JSON Value type is just a sum over subtrees and values all together, so the natural parametricity distinction is lost).

So I'd look at [0] for a wealth of examples in that vein. I'd also look into zipper lenses. They were removed in more recent versions (I think anticipating splitting them out into another package) but they're available in the 3.* series [1].

[0] [http://hackage.haskell.org/package/lens- aeson](http://hackage.haskell.org/package/lens-aeson) [1] [http://hackage.haskell.org/package/lens-3.10.1/docs/Control-...](http://hackage.haskell.org/package/lens-3.10.1/docs/Control- Lens-Zipper.html)

<comment><USER3> Yes, lens-aeson looks pretty damn close. I've got a bunch of reading to do.

The existence of zipper lenses catches me by surprise, as I have been frequently directed at a stackoverflow [0] response on the difference between the two...

[0] [http://stackoverflow.com/questions/22094971/what-are-the- dif...](http://stackoverflow.com/questions/22094971/what-are-the-differences- between-lenses-and-zippers/22097113#22097113)

<comment><USER2> I'm the author of the non-accepted answer to that question. For what it's worth, I think cgrand's is weak in describing both zippers and lenses, but ultimately lands on the wrong distinction.

</comment></comment></comment></comment></comment></comment></comment><comment><USER3> Sorry about "performant," everyone. After years of being mocked as a pedant for avoiding the word (ok, there may have been other reasons), I decided to dip a toe in the descriptivist waters. Maybe it's too soon. I toyed with "fast" in the title, but that could be taken as referring to ease of use. I'll spend the next few hours trying to come up with a better title.

</comment><comment><USER3> Ok, I managed to get a van Laarhoven representation in typed Clojure, though it wasn't exactly a smooth experience. [http://blog.podsnap.com/vanhole.html](http://blog.podsnap.com/vanhole.html)

</comment><comment><USER4> This seems to be the core of the idea, which I like a great deal:

"Type-checking is somewhat difficult with the current implementations of ph- whatever, as, intuitively, it would be with anything implemented as a recursive function that might consume and return values of different types at different levels of the stack. "

So the goal is to enable TypedClojure to work in some functions, such as assoc-in, that are recursive and difficult to type.

</comment><comment><USER5> Disclaimer: I don't know Haskell.

But I did read the article - do I understand correctly that lenses are more or less equivalent to the Common Lisp getf constructs?

</comment><comment><USER6> Performant?

<comment><USER7> I'm not sure if you're asking whether this library performs well or are picking on the use of the made-up-for-engineer's-use word "performant." I'm going to assume the latter. I think it's an OK word to use. It's a succinct way of saying something performs well. We programmers tend to have a deep history in stealing terms from other industries and butchering their meaning (orthogonal, impedance mismatch), it's about time we make up some of our own!

<comment><USER8> Well, I have no problem with making up words, but I feel like mentioning that there is an even more concise term that could be used: "fast".

Although this word doesn't have a scientific gleam or a stamp of enterprise approval, it is actually _more_ specific than "performant". Technical words are nice but sometimes they just serve to hide details. All that glitters is not gold.

<comment><USER9> * it is actually more specific than "performant"*

I disagree. See this use of 'fast' in a submission, for example: [https://news.ycombinator.com/item?id=7132044](https://news.ycombinator.com/item?id=7132044)

What does "fast" mean there? It could mean the development environments are performant. Or it could mean they're quick to implement or set up. I believe the latter is what is intended, but I can't be sure from the submission or even the article, because the word "fast" is not very specific. In this context, the word "performant" would have been much more clear.

Language is fuzzy and malleable and subjective. People shouldn't be so quick to lay down declarations of approved or preferred words. And to chide someone for using a word that hasn't made it to the dictionary yet is tantamount to declaring that we should freeze English and never change it (referring to the great-grandparent post here).</comment></comment></comment></comment>


Ask HN: How to validate SaaS MVP without writing code? - <AUTHOR> We are a team of 3 dude with a combined 30+ years in FinTech, specifically in building software for Hedge Funds, Asset Management firms and brokerages.
We've been working on a couple of SaaS products on our own, that involves SEC Filings, including Insider Trading data ( Form 4,5, 3), Holdings data ( Form 13-F) and Corporate Filings ( 10-K, 8-K etc)
We've written a lot of code, designed databases, API endpoints etc, but I'm not sure how we should validate that
1) there is a need for such a service, and
2) people will pay for this service.
I looked in Quora and reddit and a couple of quant forums, and there are questions posted asking for SEC EDGAR API, or normalized SEC filings data. But we don't have any real contacts or real target user and I don't know how to find them.
I know that your should not be writing any code and validate the need for a pain point you are solving, and I am concerned that we are coding and developing stuff for months without actually validating the MVP / finding Product Market Fit.
I hope you understand my questions and predicament. Any advice on any of this would be really helpful.
Last thing I want to do is spend months coding and building and then find out 1) no one wants this or 2) no one will pay for it cos it's not a painful enough pain-point or there are already established players (i.e. problem already solved efficiently)
Thanks in advance.
[ If you have more questions or want to advice / help me in private, my email is in bio.] <comment><USER2> Sounds like you need to figure out who/where your customers are. Seems pretty niche, how do people find this information today? What kind of jobs / industries need to know about the info you are curating?

</comment><comment><USER3> Ask for money from a customer. If they provide it, build the thing. If not, try offering something else. If you run out of ideas and cash, get a job.</comment>


Postmortem of last week's fileserver failure - <AUTHOR> http://github.com/blog/666-postmortem-of-last-week-s-fileserver-failure <comment><USER2> Server-side data loss always sucks, but this would be much harder to recover from with a non-distributed VCS. Another win for the D.

</comment><comment><USER3> I absolutely love postmortems. I think it's because I love seeing the complex ways our dear friend Murphy works. Also, it's really nice to be able to see problems other people run into, so you can avoid them or plan for them yourself.

</comment><comment><USER4> I find candid postmortems indicative of a dependable service. Good work Github.

</comment><comment><USER5> THIS is how you handle failure. You learn from it, and let others learn as well.

</comment><comment><USER6> I love how up front those guys are.

</comment><comment><USER7> This is a classic example of how the naieve plan of 'Get two servers and mirror them' can lead to downtime regardless of the best intentions of sysadmin.

<comment><USER8> Maybe the best comment about this issue.

The problem with the GitHub RAID approach + daily snapshot is that you end up with only the equivalent of a daily backup and you do not have data integrity insurance.

Each of their file storage pair is running in RAID + RAID over the network (DRBD). RAID is not a backup because you can get data corruption and you just replicate the corruption.

Imagine that they got part of their A server having issues, which are with current FS+RAID simply ignored. You can run months without integrity check even with Git because if you add new objects and do not need to repack, no integrity check is performed on the old objects. So your corruption spread from A to B (RAID) to backup (daily snapshot). Then you need at home to checkout because you lost your HD, you are doomed. Full data loss without a single warning. If you are a single developer on your own private project, this scenario is easy to achieve.

I really really like the way Fastmail is doing backup. They are replaying the IMAP operations with checksum. With Git you can also replay with checksum too. In fact, it is built in thanks to the DSCM nature of Git.

For the backup of my customer git repositories, this is what I am doing, in the post-update hook, I fire a git sync with git on another server, it is doing everything needed while being CPU+bandwidth efficient. Thank you git.

The easy way to do it: <http://kerneltrap.org/mailarchive/git/2007/10/18/346839>

</comment></comment><comment><USER9> > Prior to the failure, we had been seeing some anomalous behaviour from the A > server in this pair. The machine had been taken offline and memory tests > performed, but no issue was found.

Presumably the anomalous behavior was disk-related and yet they only test memory.

Why not check SMART status? Or if the RAID driver doesn't support SMART passthrough; move the drives to the SATA controller and boot off of a flash drive.

Also, there are tools to generate lots of i/o and test for failures, i.e.:

<http://www.peereboom.us/iogen/>

</comment><comment><USER10> Damn, that is sluppy. GitHub is, essentially a glorified file storage place and they don't have a wy to ensure th at corruption doesn't happen?</comment>


What widely-used single-developer open-source projects are there out there? - <AUTHOR>

This question came up yesterday, and I thought I'd ask y'all what you knew on the topic. "widely-used" is subjective, sure, so subjectivate away. <comment><USER2> Nginx.</comment>


Show HN: A simple 'lost & found' side project - <AUTHOR>

I started foundcamera.com as a basic weekend project a little while back.
I hoped to help a few people out and potentially facilitate some great success stories.
I thought it improved upon what's out there already as it's super simple (no signup) and it puts the geographic element at the centre of helping people to find & return treasured photographs to their owners.
It's recently picked up in popularity and I'm adding more lost and found items and seeing several hundred visitors each day. No successes as of yet.
Any suggestions for getting more people to play detective and help return items? I want to get some green pins on the map!
Are there any non-intrusive ways I could monetize it? Not to make a profit but at least to break even.
How could I improve it for v1.1?
Thanks <comment><USER2> Allow people to put bounties on their lost items. The finder gets a reward and you take a cut.

<comment><AUTHOR> I do like the idea of making it into a game somehow!

A few people have already posted that they will pay a high reward, however I've not included the $ figure they mentioned.

Part of me thinks people should help out, out of generosity - plus I wonder if putting such a high reward for returning treasured photographs, it makes stealing cameras all the more lucrative.</comment></comment>


Zed Shaw: You Shall Know The 20% By Their Lack Of Works - <AUTHOR> http://oppugn.us/posts/1274143375.html

<comment><USER2> Zed, it's "they're", not "their"

<comment><USER3> You shall know the 20% by they are lack of works?

<comment><USER2> "You have to take whatever they throw at you and just assume their useless total idiots like Chris here."</comment></comment></comment>


Language choices for long-term projects - <AUTHOR> http://richorama.github.io/blog/2014/12/31/languages/ <comment><USER2> This is an ill-informed opinion.

He correctly reject quite a number of language, but probably not for the right reason, given the criteria of using it for long-term projects.

What languages will be still usable in 50 years? A language like perl, that was popular a few years ago, but that nobody use anymore? A language like java or C++ that's changing every few years (because it's so limited or ill- designed)? What guarantee do we have to be able to compile our current C++ programs with C++2060? What would you bet? Even C's evolving.

On the other hand, there are a small number of candidate language that withstand the test of time:

\- Fortran and Cobol (somewhat specialized languages),

\- Lisp, notably Common Lisp which is still able to run programs 55 years old (that's my personnal bet, CL programs written today will be still runnable in the Lisp of 2060), and whose ANSI standard has not changed for 20 years now.

\- probably Smalltalk. Perhaps Ada and Eiffel.

All the other languages are too recent or evolving too fast to ensure any perenity for long term projects, AFAICS.

For example, while Haskell is the current fad in purely functional programming languages, I could count at least half a dozen of rather popular functional languages invented since I was in University, for an average of lifespan of a few years each, not much more. If I wanted to write a long term project in a functional style, I'd still choose Common Lisp to do that...

[http://longnow.org/](http://longnow.org/)

<comment><USER3> _\- Fortran and Cobol_

This is definitely the right general strategy: You want to ensure that compilers, libraries and a community are all available in 50 years. This depends, in turn, on having a huge community of users with high-value legacy systems that can't be feasibly rewritten.

So basically, you want to choose a boring, widely-adopted "enterprise" language, one used to implement a large number of critical back-office applications in Fortune 500 companies. You also want to choose a language which has a long history of backwards compatibility. In the 80s, Cobol would have been an excellent choice.

Today, I'd probably go with Java for this role. Sure, there's a lot of boilerplate (or whatever your personal complaint might be). But in 2064, there will absolutely be a huge quantity of ugly legacy code written in Java, and it will still be running critical systems somewhere. At a minimum, there will be a small market of specialists who can maintain it, and Oracle (or one of their successors) will be happy to sell you a JVM and enterprise consulting services at a hideous markup.

<comment><USER4> not to be underestimated: the jdk is open source.

</comment></comment></comment><comment><USER5> (FTA) On C#:

"For some reason bit rot in .NET seems to set in very quickly."

(FTA) On Java:

"It's been slow to catch C# up on language features"

These two observations (which are independently correct) are inter-related in a way that materially impacts what decision I'd make if I were really forced to make one similar to this article's thought experiment.

(FTA) On Java:

"I haven't done much Java, and I'd like to keep it that way."

As someone who programs in Java almost every day (Android development), I respect this opinion because there's a lot about Java that I hate, _but_ if your goal is honestly to create a system to be maintained on the scale of decades Java would probably be the best, most practical bet of any of the languages mentioned, by far.

It isn't sexy, it often isn't fun, but in my experience (which involves programming in Java off and on in various contexts since the mid-1990s) it hits the biggest cross-section of development system/runtime that bit-rots the least and is most likely to still be around for 10+ more years (even if this is much to my chagrin). This doesn't mean I'm a fan of Java, I'd much rather code everything in Go, but Java is the safe bet given the premise.

Before anyone brings up picking Java over C/C++ (which are older languages and still have robust ecosystems), try compiling K&R era C code with a modern compiler. Java is ironically like the (pre-Windows Vista) Windows of programming languages in that the tools and runtime basically bend over backward to not break your old code that used to work, this is both good and bad in different contexts but is very useful for the specific niche of development this article is talking about.

</comment><comment><USER6> Seriously one of the worst posts I've seen on top page in a long while.

Disclaimer: from here on I'll also be a bit opinionated, hardly can be worse than the post. And yes he did write the disclaimer, and no, still doesn't help at all.

Just LOL.

What's the difference between Python and Ruby and the conclusion?

Scala doesn't get him excited? Well, can be if he's "not clever enough to program in Haskell". (Not a bad thought-terminating cliché btw)

The best: "limited compile-time safety (you can lint and unit test)" of node? And is offset by "not creating a large codebase!" ?!

Half the languages he mentioned are less verbose than JS.

Oh, and he didn't mention the coolest feature of JS: weak typing, which works perfectly for long-term projects.

On the other hand Lisp? Ah, I'll stop here.

He could have just written "here are the languages I'm currently interested in" and be done with that.

<comment><USER7> > _He could have just written "here are the languages I'm currently interested > in" and be done with that._

To me he did. I saw this as a casual listing of what languages he wanted explore next by ruling out the ones he didn't want to learn because of one or two things in each that he didn't want to contend with.

</comment></comment><comment><USER8> This blog post is absolutely maddening.

He wants a language choice for a 10+ year project and dismissing Java because it doesn't evolve fast enough. That is one of the top attributes you want for a long running project.

Being OK with Elixer and Clojure but dismissing Erlang and Java is insane when the former are much more likely to break compatibility.

</comment><comment><USER9> On Rust:

       An interesting language, but rather than taking
       an opinion about how software should be built,
       Rust just seems to throw everything at you. You
       can be functional, object-orientated or procedural.

You can write functional and procedural Rust code. It's really, really hard to write object oriented code except in the "object oriented C" sense. For instance, there are no classes or inheritance as such.

And Rust seems to have a pretty strong opinion about how software should be built, mostly centered around correctness and safety, which seems to be an underserved niche.

Perhaps the author should read through the Rust Guide, which has been recently written and is a great intro to the language: [http://doc.rust- lang.org/guide.html](http://doc.rust-lang.org/guide.html)

</comment><comment><USER10> This isn't even about long-term projects, it's more about the author's personal preferences.

Erlang is dismissed with "the Erlang syntax itself is a bit odd" and other languages (rust, Python, Scala) are dismissed as they don't _feel_ good.

The article is a bit shallow.

<comment><AUTHOR> yeah it is, I'll try harder next time...

</comment></comment><comment><USER11> Nice comparison. I believe every language has a purpose.

Ruby is a good choice for front end. We use them to build front-ends ([https://github.com/megamsys/nilavu](https://github.com/megamsys/nilavu)).

Go is a good choice for system programming, its native binary interests everybody.

Nodejs is good choice for realtime programming.

Scala is concise and good when you need heavy duty API and such and allows to build a robust code ([https://github.com/megamsys/megam_gateway](https://github.com/megamsys/megam_gateway))

<comment><USER9> > Nodejs is good choice for realtime programming.

...for some definition of realtime. Javascript and node.js are terrible choices for serious signal processing systems, for example.

We really need to find another word for the kinds of browser applications people call realtime these days.

<comment><USER12> I propose: Humantime. Humantime means that you react as fast as person would give a crap about.

</comment></comment></comment><comment><USER13> With the way I see young developers shy away from anything-legacy, and the way new languages and fads pop up on a monthly basis, I can hardly believe ANY software is going to last 5 years, much less 10 to (yeah-right) 25.

I basically assume whatever I'm working on today will be gone in 5...now obviously, it's very dependent on how deep in the soup you are (COBAL is still being run on banking systems etc etc), but still...I don't see a lot of legacy-code maintenance and extending skills being developed as they once were.

</comment><comment><USER14> I think this is best taken as a half-serious, somewhat comedic take on these languages in the vein of PG's [http://www.paulgraham.com/fix.html](http://www.paulgraham.com/fix.html). Some of them are quite funny. I also think that a large consideration is whether the author is personally interested in trying each language, which rules out many languages that are reasonable choices from a purely practical perspective (Fortran, Ada, etc. mentioned elsewhere).

</comment><comment><USER15> A few months ago, after reading on HN about long-term (forever) side projects, I decide to write a kind of personal tracker/ todo list/ personal knowledge base mix up (basically, a "this is my life"/ "this is my brain extension" app). I went through the exercise to pick a language, with the following criteria:

\- The language will need to be usable for the next, let's say 20 years.

\- The project will forever has only one developer, and one user (both me). That means I can pick whatever exotic language I want without any concern.

\- Following from the previous criteria, it means the most important - if not only - necessary characteristic of the language would be programmer productivity.

\- This is more of a point on framework rather than language. From the first criteria (long term), it means that it's probably safe to ignore any, and everything that is currently popular. Chance are those would be too bloated, and one they stop being popular, whatever productive was gained will be lost with dealing with the cruft anyway. Also, what's the rush in gaining productivity early on in the project anyway.

\- If I can actually keep hacking at it, I might imagine myself using it on multiple devices. Also, I will probably be using a combination linux/freebsd/mac/windows a few times in the next 20 years that marrying to .NET or similar is a no-no.

\- It has to be a reasonably "fun" language.

There are a few more criteria, but they're just natural extensions of those mentioned. Anyway, it was a pretty simple decision that it will probably have a backend API of some sort. But what about the frontend? A JS single page app seems to be fitting at first (multiple devices/ platform), but miserably fail the longevity criteria. Even without any framework, the current rate of change in JS/HTML means that I will have to keep redoing the entire frontend every few years.

Actually, on second thought it seems impossible for UI to be long lasting, for the simple reason that UI have to be specific to the platform. So I just decide to ignore mobile for the moment (that was a far-fetched plan anyway).

Without elaborating through each language. The first short list was actually a pretty easy choice of Common Lisp, Racket and Smalltalk (Pharo). With the choice of UI, I decided to go with Smalltalk!

</comment><comment><USER16> If it is a distributed system of various components, then use a solid connection/communication layer which has a C interface and bindings for basically everything (maybe ZeroMQ or ProtocolBuffers or?). Make sure to document the protocol well and you can exchange and mix languages at will.

</comment><comment><USER17> In case anyone is curious about any of those languages:

[http://learnxinyminutes.com/](http://learnxinyminutes.com/)

</comment><comment><USER18> Obligatory: [http://www.paulgraham.com/hundred.html](http://www.paulgraham.com/hundred.html)

<comment><USER16> I don't think Paul Graham's Arc will be around in a hundred years.

</comment></comment><comment><USER19> I agree with some of the observations, and not others.

On Java...

 _I haven't done much Java, and I'd like to keep it that way. My impression of the language is that too much time is spent doing the boiler plate. It's been slow to catch C# up on language features, and Object orientation doesn't seem to be the right approach anyway._

Yep. Correct. Nailed it. I wrote about "Java Shop Politics" in 2012 ( [http://michaelochurch.wordpress.com/2012/04/13/java-shop- pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/) ) but the truth is that any big-program methodology is going to become a political quagmire. The problem is the business bastardization of OOP, which isn't limited to Java. I'm sure that companies that identify as ".NET shops" are just as bad.

Clojure...

 _I have played around with Clojure a bit and I like it. However, it seems like a language of compromises, the biggest of which is sitting on the JVM. Is this a stepping-stone language, or a long term viable option? It's hard for me to say._

Everyone should be exposed to Clojure. The JVM is incidental. The Clojure community (and this is damn surprising, given that the language lives on the JVM, and Java's community is so awful in this regard) has excellent aesthetic sense. I haven't used core.async or Om for any large projects, but I'm a huge fan of what the Clojure community's doing with the front-end. In terms of aesthetics, I think they're still 5 years ahead of Haskell.

Speaking of which...

 _I'm not clever enough to program in Haskell._

Yeah... I'm going to call that a cop-out. For a 1-month project, don't use Haskell if you're not familiar with the language and not intent on learning it. Use Python or Clojure. For a _long-term_ project, you can use Haskell. It's not about "clever enough". Sure, Haskell has some wonky terminology (monoid, monad, functor) and learning everything that's possible takes years, but anyone who's smart enough to program can develop a basic capability in it.

Personally, my choice would be Python for a short-term project, Clojure for the mid-range, and Haskell for a long-term project that's destined to go multi-developer.</comment>


Developing V8 with Guix - <AUTHOR> https://wingolog.org/archives/2015/08/04/developing-v8-with-guix <comment><USER2> I wonder if wingo knows about the 'guix environment' tool or not. It can create dev environments with the correct environment variables configured on the fly, without creating a new profile or polluting an existing one. Profiles are still useful for persistence, but I use 'guix environment' for all of my day-to-day hacking so I don't have to periodically delete generations of a profile in order for the GC to collect them.

</comment><comment><USER3> I've tried using Nix a few times. The idea is in principle not bad, but the actual deployment for, say... an API endpoint? Horrendous.

Problems include:

1\. Scripts deployed almost never appeal to /usr/bin/env, they tend to hardwire interpreters to /bin/sh. This flat out doesn't work in NixOS, and the Nix team is ideologically opposed to maintaining a compat layer for specific cases like this.

2\. Compiled binaries are compiled to this SPECIFIC version of Nix. That may not seem like a bad thing, but the reality is that it's very abusive to work with. Your binaries cannot even be invoked becuase they cannot _find_ their links (including, you know, the C bootstrapping lib). This means you can make an executable on your dev box, try and push it to prod, and because prod doesn't have something like a dtrace library the entire system is incompatible with your executable.

3\. There are tools to assist with these problems, because they're so common. However, they themselves are full of edge cases they don't solve for that they're very hit-or-miss. While this isn't bad in and of itself, it tends to make the established userbase very unsympathetic and often very formulaic when you approach them with more subtle linking issues. This can be quite frustrating.

I found the entire system somewhat unworkable. I also feel like Docker or Rocket solves a lot of the practical problems I have there, despite protestations. Container images are perfectly reproducible, but also easy to update. They also tend not to rip themselves apart if you, in a moment of intellectual weakness, give a slightly confusing order to the nixos package manager and rip your system in half.

<comment><USER2> I don't know what software you were using, but it doesn't sound like Nix.

1) Your scripts should be part of a package. I don't know about Nix, but in Guix we have a build step that patches shebangs to remove the nasty /usr/bin things and replace them with references to the right executables in the store.

2) You can copy the closure of a build, that is the build your are interested plus _all_ of its recursive dependencies, to another machine and it will work just fine. In fact, this feature is a big part of how we produce the Guix binary tarball. Yes, the output of a build is a function of the version of Nix/Guix used to build it, but that has _no_ bearing on whether or not you can run the resulting binaries on another machine.

3) Given that problems 1 and 2 are invalid, I don't know what else to say to this.

Docker and Rocket do nothing to solve the problems that Guix and Nix solve. Container images are _not_ reproducible. You and I can build an image from the same Dockerfile and I guarantee that the checksums would be different. Reproducibility is being able to build the same thing N times on M different machines and get the same exact result, bit for bit. Guix and Nix are getting us to this goal, Docker and Rocket do nothing. Also, you cannot "rip your system in half" with Nix or Guix. They provide roll back facilities to undo bad changes to user profiles or the system configuration.

<comment><USER3> > I don't know what software you were using, but it doesn't sound like Nix.

I love how the initial reaction by every Nix user is to imply I'm a liar or just titanically stupid. Like it's not possible that a relatively new linux distribution that has just undergone a major overhaul of its package management system might still have bugs or issues.

No. NixOS is perfect for everyone today. Just completely rewrite every deploy script you have from the ground up. Having trouble? Don't worry! The documentation is "getting better."

> Your scripts should be part of a package. I don't know about Nix, but in > Guix we have a build step that patches shebangs to remove the nasty /usr/bin > things and replace them with references to the right executables in the > store.

Sorry, but I will not be writing an OS-integration package for every specific software deploy during development. It's unlikely to even imply that I should be doing this during development just to get off the ground. I tried to use NixOS as an environment for development for Golang and Java and found it frustratingly at odds with all existing tooling. The only languages I found that seemed well supported was haskell and C, and I don't ship code on either of those platforms anymore.

It was _doubly_ unlikely early this year. The documentation was in utter disrepair and more than two Nix developers told me on twitter, "It is very difficult to do unless you are a contributor." It was also the case that many pre-existing packages were done incorrectly, still suffering these problems. Golang's package was one of them.

> but that has no bearing on whether or not you can run the resulting binaries > on another machine.

Copying a closure to deploy software projects currently in development is an extremely intensive step, and many packages had outstanding bugs that don't do this.

Furthermore, existing deploy tools like Puppet, Salt and Ansible all have extreme difficulties managing this model, but Nix (at least at the time I examined it) didn't offer very good tools for actually distributing said closures in a cloud services environment.

> Container images are not reproducible. You and I can build an image from the > same Dockerfile and I guarantee that the checksums would be different.

It's not the responsibility of the _dockerfile_ to maintain this immutability. It's the responsibility of the environment the dockerfile is executed in.

Which is probably why Golang was specifically such a problem, it has a really miserable story for actually making reproducible builds with locked deps.

Given a specific git SHA for a project with locked dependencies, it is absolutely reproducible and will produce the same image SHAs every time.

P.S., at the time NixOS was going through a major update and it was possible to install a version of Nix onto NixOS that was not entirely compatible. This ruined the install while still using Nix commands. If that bug has been fixed, great, but it was a known issue and I was not the only person in IRC asking for help with it. You lost your ability to roll back.

</comment></comment></comment><comment> vezzy-fnord _They use "deco" as an init system, for example, which is kinda like systemd but not._

The init system is actually GNU dmd. deco is the name of the control utility (like systemctl is to systemd).

It also has absolutely nothing in common with systemd, so I don't know why the author made that comparison.

<comment><USER2> It's hard to talk about an alternative init system without comparing it to systemd these days. I wish wingo would have mentioned _why_ we use dmd in the first place. It's not out of systemd hatred, but rather for better system integration. dmd is written in Guile Scheme, just like Guix, and that gives us the two programs really excellent integration with each other. dmd needs more love to approach the feature set of systemd, but I think using it is the right choice for the long term. In addition to using it on my GuixSD systems, I also use it as a user service manager at work and it works great. Also, there's a proposed project out there for someone to implement a Guile reader that reads in systemd unit files and produces the equivalent dmd service object. If this is done, it should assist adoption, or at the very least experimentation.

</comment></comment><comment><USER4> > but it is just unacceptable and revolting that software development in 2015 > is exposed to an upgrade process which (1) can break your system (2) by > default and (3) can't be rolled back.

I would like to add that building a system that makes it difficult to reproduce the exact same state on another machine, even if the central/distributed repository it originated from is not available, should be considered malpractice.

</comment><comment><USER5> Just an anecdote: Since I started using Slackware Linux, I have never had any problem with my system.

I like the idea of functional package managers, Guix especially. But for me personally the problem they are trying to solve does not exist.

<comment><USER6> Functional package managers (FPM) to me are a viable solution to (cloud) deployment: what is the difference between a FPM controlling the totality of inputs and outputs of an application, and modern containerization solutions such as Docker, really?

I've played with Docker (and rkt) and there's something off putting about using this stuff in production, to me at least, while I'm itching to see how Nix and Guix grow; waiting for someone with more free time than me to really cultivate this potential.

Nix is more mature, but I dislike the Haskell syntax. I love Scheme, but I hate the free-software-only-religion around GNU Guix: I appreciate what GNU does, I'm a regular GNU/Linux user, but at this stage of development religious beliefs are just a hindrance to adoption and it makes me sad.

EDIT: and let's not forget about node provisioning, something you can already do with NixOS (no idea about GuixSD): forget Ansible and its declarative configuration, but define the totality of the system state and configuration in a single file. Tell the machine "OK configure yourself like this", and voilà, you have a node which is (formally?) proven to be exactly like you've described. That's the future.

<comment><USER7> Among functional languages, I wouldn't call nix anywhere close to haskell. As for the free software, sounds like a typical baseless meme I've heard many times.

<comment><USER6> > sounds like a typical baseless meme I've heard many times

Is it though? I'd probably install GuixSD on a virtual machine if I knew most of the non-free software are used are packaged or at least accepted [1]. This means more users, which means more contributions and it's realistic for the project to go somewhere.

I can give you a baseless opinion I don't have any fact to show for but I don't think it's so hard to see: many GNU projects are very cool but for some reason they fail to reach critical mass and they just seem to grow very slowly (or die a slow death, depending on the point of view.)

1:

> [...] the GNU distribution follow the free software distribution guidelines. > Among other things, these guidelines reject non-free firmware, > recommendations of non-free software, and discuss ways to deal with > trademarks and patents.

[http://www.gnu.org/software/guix/manual/html_node/Software-F...](http://www.gnu.org/software/guix/manual/html_node/Software- Freedom.html#Software-Freedom)

<comment><USER7> There is adoption & attraction of development because software has freedom.

There is adoption & attraction of development because software does not have freedom.

They are not mutually exclusive. gnu, debian, etc are fundamentally driven by the goal of making a completely free operating system, and they would have much much less adoption and development if they weren't. We now have and are gaining more hardware which is completely free. If we don't make software distributions which are completely free, we will never have completely free operating systems, and we won't be encouraging people to use completely free operating systems.

</comment></comment></comment></comment></comment><comment><USER8> Huh... I had no idea Nix and Guix could be used this way. I viewed them as replacements to _apt_ , but what I'm hearing is I could just as easily use it as a souped up _stow_... interesting...

</comment><comment><USER9> IMHO, there is only a little bit of separation between Docker and Nix/Guix.

I wonder if the Linux desktops of tomorrow will be a thin hypervisor (or something like CoreOS), running a immutable VM on top.

<comment><USER2> There's quite a lot of separation, IMO. Docker uses an imperative, stateful system for image creation that doesn't actually help with reproducibility and specifically only creates container environments. Guix and Nix use a functional, declarative system for building anything (software builds, VM image creation, etc.) and can create any type of environment, including containers. Guix and Nix are much more general-purpose and are built upon a stronger foundation.

So, rather than using Docker running Debian/Ubuntu/whatever images and another OS entirely managing the host, you can use Guix or Nix to manage every layer and take advantage of their very advanced features everywhere.

<comment><USER9> Actually I would argue that Docker is more flexible than Nix/Guix. The usecase for package managers are installing packages, whereas Docker combines package management along with configuration management.

Think about Nix+Ansible - that's what you really need if you are going to have a true stateless system. Take your base packages to create an immutable snapshot and then layer your configuration changes on top of them.

<comment><USER2> Actually, Guix and Nix aren't _just_ package managers, they also provide a fully system configuration management tool complete with the ability to roll- back to earlier versions of the system. You don't need Ansible or Docker when you use Guix or Nix. The same framework for providing reproducible software builds is also used to provide reproducible system configuration.

See: [http://www.gnu.org/software/guix/manual/html_node/Using- the-...](http://www.gnu.org/software/guix/manual/html_node/Using-the- Configuration-System.html#Using-the-Configuration-System)

<comment><USER9> very interesting - thanks for pointing that out. Ergo my statement that Docker and Nix/Guix will converge at some point. There is already an overlap: I believe Docker has mindshare, but it is unusable on desktops.. whereas Nix/Guix was designed for desktops, but is losing out because most people use Macs!!

It would really be something to build a ESXi for Docker/Nix/Guix and be able to provision fully functional VMs on top of it.

<comment><USER10> I am currently using the Nix packager on a Mac and it works fairly well. It's not as smooth as Homebrew but it's getting there. See [http://nixos.org/nix/](http://nixos.org/nix/) -> Get Nix

</comment></comment></comment></comment></comment></comment><comment><USER11> What's the significance of "V8"? He means the javascript engine, right? But that never enters into the story.... It's really just "Developing with Guix".

<comment><USER2> Towards the end of the post he shows how he creates his reproducible v8 dev environment.

<comment><USER11> My bad, I didn't make it that far. Dude spent the first half of the article bitching about his Debian box, and I skimmed the rest (apparently not very well).

<comment><USER12> He explains how nix/guix technology in the realm of personnal computing can improve day-to-day work, in this case the work of a developper. Wingo's setup is kind of complicated: nixos+guix. (I use only Guix OS for Django dev). In my case, Guix is overkill most of the time, since most dependencies are python. Guix can also replace virtualenv taking into account binary dependencies..

Binary dependency is the case met by Wingo.

I think he does not stress enough (first part) the fact that upgrading is painless in nixos and Guix OS (almost, it's still alpha) compared to debian- like distros.

Guix is a good idea. It needs more packages that is all.

</comment></comment></comment></comment><comment><USER13> I'm a little surprised that a veteran Debian user would fall into this kind of trap (again :). I think guix looks very interesting, but a couple of tips if "all" you need is to "code on the edge" in Debian:

1) Run Debian stable. Possibly add stuff from backports if you _need_ to (eg: newer kernel for drivers. Newer xorg. Hopefully this shouldn't ever be needed for mainstream workstations - modulus closed source graphics drivers).

2) Don't mix'n'match [packages from testing/unstable with stable]. Don't pin. Just do not do it. [Don't run testing/unstable... unless you _are testing_ testing].

3) For utilities not in stable - some can go in ~/opt/{bin,lib,man} -- living in ~/opt/xstow/$package-$version/ \-- see "man xstow/apt-get install xstow" \-- and set your path, ld-path, man-path ("man man") and friends to point to ~/opt/man etc.

I also have a ~/opt/venv/util/bin in my path so I can go "pip install mercurial" without worrying about system python packages etc. If you go down this path be aware of "apt-get build-dep mercurial|python-$foo" as a reasonably sane way to get system dev headers for c libraries things you pip install in your venv(s).

Think of the venvs as disposable! Might have to trash them on a dist-upgrade and recreate. Ditto for ~/xstow.

But none of that is _much_ better than the mess Wingo found himself in, therefore:

4) Embrace the glorious trinity formed by lvm, schroot and debootstrap! With lvm-backed schroots you can have a source-chroot for each of testing, sid/unstable and experimental. Complete with rollback, named snapshots and automagic binding of $home (with among other obvious benefits - your x session cookie).

Schroot documentation/wiki/howto do need a facelift, though.

See also:

[https://www.pseudorandom.co.uk/2007/sbuild/](https://www.pseudorandom.co.uk/2007/sbuild/)

[https://wiki.debian.org/Schroot/e](https://wiki.debian.org/Schroot/e)

[https://wiki.debian.org/CrossCompiling](https://wiki.debian.org/CrossCompiling)

[Note that auto-bind-mounting home can now be set in schroot.conf IIRC -- see man schroot]

PS: If you have $home on nfs and mount it on both 32bit/64bit linux as well as Solaris... you can put stuff in ~/opt/$arch/.. and dance around in .xsession and/or .bashrc... but I don't recommend it unless you have to...</comment>


Control-Flow Decoupling: A Method for Fast, Non-Speculative Branching (2015) [pdf] - <AUTHOR> https://people.engr.ncsu.edu/ericro/publications/journal_IEEETC-Aug-2015.pdf <comment><AUTHOR> The actual title is _Control-Flow Decoupling: An Approach for Timely, Non- Speculative Branching_. I changed a few words so that it would be under the 80 character limit.</comment>


Is Chess a game of skill or game of chance? How much? - <AUTHOR> http://chess.stackexchange.com/questions/4743/is-chess-a-game-of-skill-or-game-of-chance-how-much

<comment><USER2> Neither... Chess is not a game of skill. Nor is it a game of chance. _Chess is a game of memorization_ \-- Memorize all the opening books, all solved end- games, and every famous historical game ever played, and you too can be a great chess player!

David Sirlin has a chess variant called "Chess 2: The Sequel" that uses a three-pronged solution to chess's problem of over-reliance on memorization:

(1) Pick 1-of-6 opening armies: This deals with the problem of memorized opening books.

(2) Mid-line invasion: You win if your King crosses the mid-line of the board. This new victory condition deals with the problem of memorized end-games.

(3) Dueling: Instead of simply capturing a piece, players use a double-blind bidding mechanic with a scarce resource called "stones" to decide the victor. This makes a good memory even less advantageous.

Sirlin's website is here: [http://www.sirlingames.com/products/chess-2-print- and-play](http://www.sirlingames.com/products/chess-2-print-and-play)</comment>