skysight-inc/HackerNews huggingface dataset:
I have a related anecdote but no advice for your goal of 1-2 days promo then leave it.

Once upon a time I also made some software for a similarly real but niche problem (recording, processing, and building timelapse videos of your work during hackathons). I never promoted it or anything beyond talking about it and using it within the community where the idea was born (in my case, ludumdare when it was still very small). It has actually done pretty well within that context; over the 8 years or so it has been around it has ~50k installs, and it has branched far beyond hackathons -- it made its way onto lifehacker when they still covered real products, there are a handful of completely independent reviews out there, and I get emails from time to time asking for features from a wide range of use cases (everything from documenting cell growth to filming engine rebuilds to tracking video game progress in a modernized arcade).

My only (admittedly weak) advice is to go to the source of how you knew this was a need and share it openly and honestly within a community that is either about that or clearly shares that. From there you'll get some feedback and, if it really does solve a pain point, people will use it and share it. In my story, the flexibility of the product to be useful beyond the initial problem I was trying to solve was also key to its growth - maybe you can do something similar with how your thing works.

I realize that 8 years of being available is the complete opposite of your goal of promoting for only '1-2 days', but I think that amount of participation may not be super compatible with any software these days, particularly for small 'love' projects. How many github projects have you seen that sound nifty but have an empty readme and no commits for 2 years so you wouldn't touch it with a 10 ft pole? I think you'll get much better results by trickling continued time into the product to make sure people know it is alive - respond to posts/questions about it, fix bugs (or at LEAST comment on the issues), etc.
but they accurately identify it as the same category of contraption that operates a clock/timer portion of a time bomb.
It used to be. It's kind of a bug with new.
The architecture is exciting. The problem is that the aesthetics of the tooling seems deliberately designed to alienate new users. For example the whitepaper gives new names to every punctuation symbol!

And poking around the repo, there are gems like this:

"A...variable name is a random pronounceable three-letter string, sometimes with some vague relationship to its meaning, but usually not..."

"Nock, for mysterious reasons, uses 0 as true...and 1 as false..."

The architecture is really cool, but the syntax is terrible.
Interestingly, this same objection comes up when people try to read so-called (normally French) postructuralist theory from the 60s and 70s. Derrida himself, or Rorty writing on Derrida, supposedly advanced a similar argument, that using new terms allowed one to avoid falling back onto old concepts.

I couldn't find a good source quickly, but it's mentioned here: https://en.wikipedia.org/wiki/Jacques_Derrida#Criticism_from...
In case anyone else was confused, JustFab is not in fact the same company as Fab (despite their similar names, founders named "Goldenberg" and "Goldberg" respectively, and unsound business models).

Fab: https://en.wikipedia.org/wiki/Fab_(website)

JustFab: https://en.wikipedia.org/wiki/JustFab
There's lots of reasons to use packages. Verification, versioning, bug tracking, offline use, system-install, user-install, dependency tracking, rollback, sanity checking, custom install steps, and being tested and certified for a particular repository and software branch, among others. But, you know, if you just want to install something and not know what it is, what it does, how to fix it or remove it, much less whether it's even the software you expected, curl|bash is okay.
Many but not all things can be usefully parallelized. The build, and most unit tests and integration tests can, though we struggle with the latter where real hardware is required. Some performance tests are also run on real hardware. This doesn't scale as well.
You ask a good question. It's a shame you got downvoted.

http://www.washingtonpost.com/wp-srv/national/horizon/jan99/...

> When the NLM advertised for bidders willing to cut a human body into thin slices and photograph each slice, there was far more interest than anyone anticipated. About 100 of the approximately 120 American medical schools, collaborating in various combinations, formed six consortia to apply for the contract.

> The field was narrowed to three. Each consortium was asked to submit pictures of slices, taken 1 millimeter apart, from the abdomen of an animal or human body. One millimeter is about the thickness of a dime. A committee of anatomists and radiologists then chose the best. The winning bidder was a consortium of institutions in Colorado, Texas and Maryland.

> The actual work on the cadavers – first a male, then a female – occurred at the University of Colorado Health Sciences Center in Denver. Under the direction of two scientists, Victor Spitzer and David Whitlock, the bodies first underwent head-to-toe CAT and MRI scans before being frozen solid.

> To make them easier to handle, the bodies then were cut into four pieces with a special saw. Each of the three cuts – separating the body into sections containing head, neck and thorax, abdomen and pelvis, thighs and knees, and legs, ankles and feet – lost only 1.5 mm of tissue, represented by black space in the stacked final images.

> It is more accurate to say that the cadavers were milled rather than sliced. The bodies were packed in dry ice and surrounded by a slurry of frozen alcohol at temperatures between minus 90 and minus 60 degrees Fahrenheit.

> Starting from one end of a body section, a rotary rasp ground down the tissue to a specified depth. In the male, this depth was 1 mm. In the anatomically more complicated female, it was .33 mm, providing three times as much detail.

> Each round of milling exposed a smooth, rock-hard surface in which the anatomical features were visible like the grain in a log. The surface then was photographed using both digital and conventional film cameras before removal of the next "cryosection."

> Each cycle required from three to 15 minutes to complete, and the Colorado team could do about 50 each day. The work was meticulous because, once the rasp started, there was no second chance. The tissue came off in a frozen powder, which was collected, stored and ultimately "cremated in a respectful manner," according to an NLM official.
Five ways to use technology to fight tech-driven stress
He might have less incentive, but that doesn't mean he would have no incentive. He might still choose to do this to get more money than basic income would provide. He already decided this is "easy money" compared to other work available to him. He might decide to work less, but that doesn't mean he would quit entirely.
Most implementations so far have been kind of shaky (e.g. relying on having a bunch of "unpartitioned" space on the drive, which would seem weird), but it's technically feasible to have a single encrypted volume which decrypts to two results based on the key. For plausible deniability, one would have to make sure the clean volume had recent browsing history, et cetera. Maybe this is a real-world use for ad-browsing bots.
99% of the time? Common.
Apple Music’s Functionality Failure
Evidence under attack: Congress is killing one of the best ideas in government
Universal Permissive License added to license list
Chromium is open source, and will run try jobs for anyone from anywhere around the world (we won't accept your commit without lots of checks, but we'll run your tests). That means that we don't get to rely on a lot of Google-internal technology, including our production data centers.

Also, we are compiling and testing on Mac, Windows, Linux, Android, iOS, ChromeOS, and historical versions of all of the above. That's something that a mostly linux-server-based company doesn't do a lot of. So we maintain our own datacenters with our own hardware, and don't get to take advantage of all of Google's scale.
Their opinions about things unrelated to technology are, of course, highly relevant to their technological insight.
Do you foresee Urbit making use of IPFS?
One big obstacle is that the existing trains with more passengers should & need to always have the right of way. For example, should the non-pod people be stuck at the platform if you have trouble clamping your device onto the track?
> There's no swiping, it's on your smartphone and automated ( Open app, click "go home", app says "bay 21, approx, 2 min, pod #123, 1 other passenger").

And in this hypothetical world, absolutely everyone who uses public transit has a smartphone?
> NO DOWNTIME code upgrades

This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).

Also, NO DOWNTIME in the context of services is kind of hard to qualify: I have no downtime for say, a web service, when doing a load-balancer deploy shuffle.

> incredible request responsiveness as well as reliability

"Request responsiveness" to some degree depends on language- a language is sometimes your upper-bound on performance.

Much more often, however, do I find that this is a function of application design. And yes, language design and application design heavily play into each other, but there are many, many languages that can achieve the same responsiveness/reliability concerns.

Haskell, many JVM-hosted languages are good choices.

> Immutable data

Almost every modern functional language. Many even do it (immutable data structures) better than Erlang/Elixir. Some even have interesting (state of the art) concurrency features that perform better in different situations - see Haskell STM (I wouldn't try and compare to Mnesia).

> Extreme concurrency

Haskell, Go, anything on the JVM, the CLR is catching up.

> Actor model

This is a bit of a subjective and semantic thing - many languages have green threads (though not all would necessarily fit the bill of "actor model" in out-of-the-box implementation, and not all are truly preemptive (most aren't)) - Haskell, Go are two good out-of-the-box implementations.

I know Haskell has an Erlang Actor analogue, not sure if Go does yet.

> The awesome community

I hesitate to use the word "niche language" - but most "niche languages" have great communities (albeit small ones) - possibly out of necessity.

I don't find that this scales often

(What would you call the "Java community?", where would you find it?, where are the pockets of "good?")

This is 100% subjective, but, I feel like Ruby has one of the best, largest communities. Some of that has bled into Elixir, for sure, to be fair.

---

All in all, Elixir is a great language, but I hesitate to recommend it without knowing more about GP's requirements and business.

(What if the GP needs to do very memory and CPU-intensive number crunching?)
Diversity and Unity of India
Banter is what Foursquare used to be
Pebble GPL voilation
The Pebble Time application for Android uses GPL V2 licenced software, javamail-android, yet does not provide a method to obtain the sourcecode for the application.

https://pebble.com/legal/open_source#javamail
A hybrid pod could act as an autonomous car, picking you up at your house, then merge onto and "mount" a shared electrified rail for the speedy middle part of the journey—the inside-a-city equivalent of a freeway system. Effectively, the flow would look similar to bicycle commuters biking to the subway and then getting on, but without the need for the subway train to encapsulate the pod.
I do due diligence on VC/PE projects for a living. Either their diligence partner is really poor or they simply ignored their advice. Despite having $300MM on the line, you'd be surprised how often either situation happens.
My experience with Empire Flippers: A marketplace with huge asking prices entirely dependent on the greater fool theory.
+1. Having something that can use the existing rail infrastructure in off periods would be great as a transitional adoption method. That way you have time to address the institutional jitters while still providing/proving real service.

For example, during weekends / night when the load is much lower (or service doesn't run anyway).
Sony’s cylindrical display will shake up wearables
See browep's reply above[0]. The idea is that stops do not need to be large, but stops stations every few blocks.

[0] https://news.ycombinator.com/item?id=10279524
That's a good idea. I'll add a set of optional aliases to shorten the commands as well to keep something like the current experience
It's so state of the art it currently can't even generate profiling data on ARM devices.
Yep, and because all the projects are done with zero enthusiasm and only because they have a small business budget to blow, they often have no inclination to consider a Phase II or III
Add "alias cat='cat -v'" to your login profile then.
This particular example basically connects Georgia Tech's campus across the highway, There was no plan on expanding the road. The lawns actually get a lot of use, students studying/lounging during the week and popular for tailgating on Saturdays.
Stupid Apps and Changing the World
Ask HN: Creating and Licensing Product For/From Employer
I'm currently working on an side-project, that could use some technology, that has been mentioned but not built in the day-to-day of my current employment. It would be beneficial to my employer to have ownership of this product, more than my side-project does, but it isn't in the roadmap in the short-term (6-12 months). It has no role in the immediate objectives for my employer and only ancillary benefit for my side-project, so I'm worried that they may not want to support it yet or integrate with it in the case the company pivots direction.

Should I build this for myself, hand-off ownership, and then ask for a preferential license and maybe equity compensation for the product?

Has anyone done anything like this before? Producing something for personal use and handing it over to their employer with an agreement of use.

I haven't brought it up with my CEO yet and I'm sure I should probably speak to a lawyer about this also at some point.
What do you think the standard library is lacking? I mostly wrote Ruby before picking up Elixir and Ruby's standard library is loaded with mostly garbage. I've found Elixir's std lib to be focused to the core purposes of the language but I would love to hear what you think it needs.
I bet he wouldn't switch back to whatever he was using previously unless he had a friend working there and/or it was significantly more money.

It is a little tough learning new programming languages and frameworks every year or two though. But sometimes that's fun. Is it really necessary to track the winds of development fashion? No. But mostly I think people should realize a lot of it is about whats trendy and not hard technical issues.
Use "install.sh --oh-and-don't-delete-all-of-my-files=true".

If it's not the default, it's not what's going to happen.
No more ignored issues: how we learned to stop worrying and love the issue tracker
We used to do development on various MSX machines (we were doing implementations of Logo). The machines were never designed to work in low-humidity environments (winter time in Montreal). Once I accidentally zapped four machines while attaching an emulator board. We had sets of all the custom chips shipped in from Japan, and I spent four days with the VP R&D fixing them. We got three of them to work eventually (there were no spares of the computers as they were prototypes and in short supply). Fun times.
IIRC I think one of the LinuxJournal guys reviewed a pre-production version of the Librem 13" and 15" models:

http://www.linuxjournal.com/content/purism-librem-13-review

http://www.linuxjournal.com/content/purism-librem-15-review
Is Urbit comparable to Ethereum?
I would read it a popup for an IoT article didn't obsecure the entire mobile screen and not have a working close button.
Traditional punctuation names suck. "Ampersand", "at sign", "caret"? For a language like hoon where we use a lot of symbols, that gets really tiring. Having one-syllable names for glyphs is really convenient, and they tend to roll of the tongue. Everyone's free to use whatever names they want, of course, we just find these useful. Most people love these once they get used to them.

I don't think you can judge syntax by looking at it -- you have to use it for a little while. Hoon's syntax looks hard, but it's actually rather pleasant to use.
This is only tangentially related to the topics covered in the article and your comment, but I'm curious about the Chromium project's decision to mostly use static linking.

I've always found it interesting that Chrome is shipped mostly as one big binary (or on Windows, two: chrome.dll and chrome_child.dll), whereas IE and Safari use several (one for the rendering engine, one for the JS engine, one or two for networking, etc.). My guess is that Chrome uses one big binary to minimize startup time, since the OS can just map that binary into memory and go. Am I correct about the rationale? Another way to ask the same thing is this: what would be the downsides of using a component build for releases and not just for development? If you used a component build for releases, you'd have greater parity between dev and production, and that's generally a good thing.

I also notice that there are a few modules that get their own DLLs, at least on Windows. For example, in Chrome 45, we have chrome_elf.dll, libegl.dll, libexif.dll, and libglesv2.dll; I'd think these libraries could be statically linked just like the few hundred others. Are there good reasons for these exceptions? Or are these just little details that tend to get overlooked given the rapid pace of development?
To be honest the paying per page view somehow rubs me the wrong way. It'll make me think about cost whilst enjoying the book which I don't want.

I just want a reasonable price. e.g. I bought a book today. 10 GBP for paper. 5 for ebook. Thats pretty reasonable. Still good money but acknowledges that the real life costs are much lower. If its like 3% cheaper then thats just devoid of any link to real costs.
Or after 3 unsuccessful tries, the system wipes itself.
Try: macworld, oops...macw0rld, oops... macwor1d!

There's no law against incompetence, true?
From Radio to Porn, British Spies Track Web Users’ Online Identities
Let's imagine the system engineers are smarter than that: if you have a smart phone, you can use the app. If you don't, there'd be a terminal in the station you could use. I'd imagine the engineers for this could have thought of that.
A Google paper on underground economy [pdf]
We are working on a few things.

The first is automatic retries of fast tests. If a test runs quickly and fails, it costs us little to try again just to make sure. Most of our unit tests are configured to run up to 3 times.

Another thing is keeping track of a database of individual test case passes/failures across all time. This will let us automatically mark tests as flaky if they fail often, and ignore their results programatically rather than requiring a human to manually mark the test as ignorable.

A third thing is, obviously, automatically filing bugs against the owners/authors of tests which have been marked flaky. This is controversial -- often a test is just fine until one of its underlying libraries has a race condition introduced, and the real person to fix it should be the author of that change, not the author of the test. But it is still a step in the right direction much of the time.

Many people subscribe to the philosophy that "a flaky test is worse than no test", because you think it is giving you information when in fact it is giving you none. I subscribe to a slightly different philosophy: "A test with a known flaky rate is hugely valuable". If you know how often a test flakes (statistically), then you can measure variances from that rate to detect changes. Of course, a flaky test with an unknown rate of flaky is still useless. Hence the second initiative above: measuring the rate of flake of everything.
I get the angst, and share it, on the other side of the table is a company paying you for your "full time" employment, they want to believe they have paid for all your time.

So the angst arises when you aren't really giving them all your time, you are keeping some for yourself to do things that are of interest to you and not in your employer's interest[1].

That is why they want you make a choice, either commit or don't, all in, or not. If you want to parcel out your time, then contracting is a much better way to do that, neither side feels like they are being taken advantage of.

Of course there are IP issues, and one which I hope will someday be rationalized by a better IP policy and framework[2] but contracting helps there too. You take ownership of your own "overhead" (benefits, vacation plans, etc) and then you sell the time you have to work on things either to someone else for direct payment, or to yourself as an investment in a future revenue stream.

[1] They would argue that if you have time to work on that you could have used that time to work further on your project they assigned you. Vacation and leisure, keeps you balanced so is in the employers interest.

[2] And realize that currently 'time to exhausting all the hydrogen fuel in the Sun' is looking like it will happen first.
I'm no lens expert but I'd imagine that the differences in lighting and motion in landscapes and portraiture between takes might obscure the subtle differences between the lenses themselves. The static subjects probably give a more fair comparison.
> while I've heard people remark Go is fun, it hasn't been that fun for me

Fun compared to C and C++.
E-signing and electronic contracts are all over now...heck, most of the patents I filed with the USPTO were e-signed. If they don't provide much evidentiary support of...anything...then our legal system is in serious trouble.
Given that the video was already a bit old, this is the latest official statement I could find, from 29 Apr 2015.

http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17...

"Q. What about the C99 Core Language, or the C11 Core Language and Standard Library?

A. Our top priority is C++ conformance. We've implemented the C99 Standard Library because C++11 incorporated it by reference. C++ (up to the current Working Paper) hasn't incorporated the C99 Core Language in its entirety (only a handful of features, listed above), nor is it ever likely to. It may incorporate the C11 Standard Library at some point in the future, but that hasn't happened yet.

In VS 2013, the compiler team implemented some C99 Core Language features in C mode (e.g. designated initializers, see MSDN for the full list), in order to support some popular libraries. "
Vid of talk on yt: https://www.youtube.com/watch?v=rMItsZq_n20
Epistemic learned helplessness (2013)
+ a new model ferrari every year.

Or ~every 7 months for scribd who mention in the article 5 frontends in 3 years!
I presume you're referring to Smule suing Shred, which I think has gotten so much attention (deservedly) because it's so rare. Off the top of my head I can't think of another such example, but I can think of scores of side projects turned into companies, including my own, without employer interference.

You should take precautions of course--read inventions agreements very carefully--but I wouldn't at all go so far as to only do contracting. Especially if you live in California, as others have noted. Half the companies in SV were started by people working at Google or Facebook.