Ask HN: Why isn't Plan9 popular? - <AUTHOR> Hello, I don't have an elaborative question. I 'discovered' Plan9 yesterday. It seems like Plan9 was the successor to Unix. So why don't we see it in the mainstream?
What seemed intriguing to me was that for the last 8 years with all the linux/unix around, I never came across any references in - books/blogs/articles.
link: http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs <comment><USER2> "Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough."

\- Eric S. Raymond

It's worth noting that Plan 9/Inferno are cited pretty regularly in computer science papers and a number of the ideas of P9 have been absorbed by Linux, such as representing 'everything' with the filesystem. Last I checked, the 2.6.x kernels also support the P9 protocol.

"...for the last 8 years" Yeah, well, Plan 9 hasn't had an official release since 2002.

<comment><USER3> Ya, I had never heard of Plan 9 until I started doing graduate work, and then one in ten papers somehow referenced plan 9, and almost every single operating system paper references it some how.

</comment></comment><comment><USER4> A lot of Plan 9 innovations have appeared in Linux. One of the outstanding issues are _union aka. overlay filesystems_ , and these are currently being addressed.

That said, Plan 9 seems to see continued use in some niches. For example, Plan 9 has been ported to Blue Gene.

(What's kinda cute is that the Plan 9 kernel (including TCP and such) has fewer lines of code than the Ruby _parser_ , 8000 vs 10000, IIRC.)

<comment><USER5> I'd add union/overlay filesystems are in FreeBSD since at least 6.1 and became stable ca 2007. I use this stuff quite often.

</comment></comment><comment><USER6> (In my opinion) Here's a bunch of reasons why Plan9 isn't popular, and then a reason or two why something like it likely will be before too long:

The first obvious answer (also mentioned in other comments) is because "Systems Software Research is Irrelevant". See Rob Pike's paper by that name: <http://herpolhode.com/rob/utah2000.pdf>

To the reasons Pike offers there, I'll add:

1\. The companies that owned the software had poor strategies for encouraging widespread adoption, if that was even ever their goal.

2\. The first dot-com boom ca 2000 greatly expanded the IT / programmer workforce and (I claim) significantly dumbed it down. The advantages of a new operating system lack economic impact until a huge number of programmers are trained to use those advantages. We have huge sunk costs invested in maintaining a huge supply of mostly weakly skilled programmers and admins, a sort unlikely to adapt to and adopt a new OS.

3\. In a related way, the sectors that could in principle drive something like Plan 9 adoption are heavily invested, by now, in massive amounts of bloatware that, dysfunctional as it is, is both critical and non-portable.

4\. Modern hardware is fast enough that fairly high level programming languages and environments tend to dominate. These often include a "least common denominator" view OS capabilities so that programs port easily among Windows, Linux, Unix, MacOS, etc. This hurts demand for OS features other than the "least common denominator".

\</comment><comment></comment><comment>-----

Why it might get better:

Notice that _none_ of the reasons listed above apply to a market niche like "the OS for Google's clusters" or, say, massive clusters providing an SQL- based RDMS.

On clusters like that:

1) You don't need a mass audience of buyers for a new OS. One or a few big customers will be plenty.

2) You don't care about hordes of cheap, weakly skilled programmers. Paying experts is peanuts compared to your hardware, power, and real estate costs.

3) You're not tied to bloatware. You need only run a few things very, very well.

4) You don't need to do "least common denominator" programming and, in fact, any new OS feature that can save you some $s per server-hour is potentially a huge win.

My betting money is that Pike et al. will produce YANOS (yet another new OS), quite possibly mostly written in the Go programming language, really well suited for huge compute clusters.

<comment><USER7> I'd put more money on enough people finally paying enough attention to DragonFlyBSD for it to really gain traction.

Check out the blurb on their main page (<http://www.dragonflybsd.org/>):

 _The DragonFly project's ultimate goal is to provide native clustering support in the kernel. This involves the creation of a sophisticated cache management framework for filesystem namespaces, file spaces, and VM spaces, which allows heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also involves being able to chop up resources, including the cpu by way of a controlled VM context, for safe assignment to unsecured third-party clusters over the internet (though the security of such clusters itself might be in doubt, the first and most important thing is for systems donating resources to not be made vulnerable through their donation)._

If anyone truly "gets" cloud computing, it's these guys. And they have the advantage of not being quite as big of a jump from existing systems as Plan 9 is.

<comment><USER8> > which allows heavily interactive programs to run across multiple machines > with cache coherency fully guaranteed in all respects.

Cache coherency gets increasingly expensive with scale. At some point, the costs exceed the benefits.

The location of point depends on lots of things, but if you're on the other side....

Also, there are many kinds of coherency.

</comment></comment></comment><comment><USER9> IMO Plan 9 didn't gain critical mass because Unix is still "good enough". It's also very difficult to keep current with hardware drivers for a niche OS.

However, there are some things that came from Plan 9 that are very much mainstream, the most notable being UTF-8 which was invented by Ken Thompson and first implemented on Plan 9. Linux's clone(2) system call is obviously inspired by Plan 9's rfork.

And one could argue that the Go language is a spin-off of Plan 9 as it's substantially implemented by Plan 9 refugees to Google (Ken Thompson, Rob Pike, Russ Cox) and is explicitly descended from other languages that came out of Bell Labs (Newsqueak, Alef, Limbo). Of course whether Go will be a success is an open question, but I think its chances are as good as any other equivalent language.

<comment><USER10> Speaking of Plan 9 and Go, I have to ask the same question: why isn't Go more popular?

<comment><USER11> It has only been out since November 2009, and it wasn't considered ready for production then. Maybe it is now, but it definitely hasn't had much time to be establish a large user base.

<comment><USER12> Go is in a "public beta" status, i.e. what you see right now is its development, not its refinement. It basically hasn't reached a 1.0 release version yet. Participants of the mailing list are very early adopters who write some libraries for it. It's still likely enough that important parts of the language spec will change in non-compatible ways, and especially the standard library still isn't too stable (e.g. the http module is a bit orphaned right now).

But the progress is quite impressive, and it might hit a niche for lots of people (those Zed Shaw tends to call "longbeards"). Unix systems programming is still dominated by C, as there aren't that many valid alternatives. Java is systems programming for the Java system, C++ is C++. Ocaml is probably one step too far for bit pushers. And then there's the pedigree of the developers.

I think within a year the language should have matured enough. If someone manages to come up with a "killer application" for it (c.f. RoR/Ruby or node.js/server-side Javascript), it might take off.

It might also end up like Modula-3.

<comment><USER13> What about D?

<comment><USER12> That's a good question. D has been around for quite some time, has some well- known names (Bright, Alexandrescu), but has yet to break big. Compared to it, Go, a much more recent development, tends to do quite well (just my estimates, PL mindshare is a bit hard to measure).

I think it's mostly because of some internal and positioning issues. I haven't been following it recently, but I remember some problems with different standard libraries, D 1 vs D 2, and three compilers that each had issues. Maybe that's resolved, but it certainly didn't make things look too good.

Also, it seems to be more a successor to C++, which makes some people a bit distrustful. Yes, it's much cleaner, but also quite a bit more complex than C, and not a total programming environment as Java or C#. So it mainly gets its users from the C++ camp, which isn't the mightiest army nowadays (And whose Windows battalions aren't supported very well by D).

Go is in the news a lot because of its Google and Unix (Pike, Thompson) heritage, because it's a bit simpler (more C crossed with Python than ++C++), and because it has some prominent concurrency support, which is close to the current hype (every emerging language has to prove its mettle there).

By the way, don't read this as a value judgment. It's just a personal assessment why I think that Go is currently a bit more popular and will continue to be so.

<comment><USER9> Although D has been around for longer, it's worth out that the Go amd64 (aka x64) compiler is the most mature compiler in the Go compiler suite (ARM, x86, amd64) but AFAIK the D compiler is only available for 32-bit x86.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> They open sourced it too late for it to get much traction, I think.

Also, does it solve any particular problem in such a way that it can't be ignored? Doesn't seem like it to me.

<comment><USER15> There were the problems with the license for some years.

<http://www.gnu.org/philosophy/plan-nine.html>

Once it became "free" it had too little functionality.

There's too little of the software and it's not so easy to port the existing Unix/Linux software:

[http://plan9.bell- labs.com/wiki/plan9/porting_alien_software...](http://plan9.bell- labs.com/wiki/plan9/porting_alien_software_to_plan_9/index.html)

Moreover, very, very little of the hardware is supported.

<comment><USER14> Yeah, it wasn't open source. _Edit_ : wikipedia says it was only open sourced in 2002.

Incidentally, the 'crossing the chasm' approach would be to find some niche where a new OS _could_ succeed - perhaps something where the network effects were less pernicious.

</comment></comment></comment><comment><USER16> It's worth looking at Rob Pike's (one of the Plan 9 inventors) paper, "Systems Software Research is Irrelevant": <http://herpolhode.com/rob/utah2000.pdf>

My own view is that Linux is Good Enough for most people. And that "good enough" beats "better", at least for most values of "better". This is an admission that "path dependence" matters for the operating system market, and that network effects can cause the appearance of market failure.

</comment><comment><USER9> FWIW, if you're interested in Plan 9 it's also worth checking out Plan 9 from User Space (<http://swtch.com/plan9port/>): "Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems."

</comment><comment><USER17> I use Plan 9 extensively and intensively, and I believe there are multiple reasons why it is comparatively little-known and little-used. I think the most important reason is the historical conflict over software patents between Rob Pike and Richard Stallman, and the cultural rift that it represented. Plan 9 is now under a pretty decent permissive license, but it still doesn't really function in the manner of a conventional open source operating system project. By the time Plan 9 was under a decent license, the mindshare of FOSS developers and the corporate ecosystem were already completely committed to other projects.

Plan 9 is still relevant and interesting and _useful_ for some tasks. It may still be ahead of its time. Plan 9 has had data deduplication for about a decade, years before network data dedupe storage appliances became an important product. The Linux kernel is still struggling to figure out a decent way to implement union directories in filesystems, but unions have been working elegantly in Plan 9 since its early days.

</comment><comment><USER18> My theory is this:

\- too weird - Plan 9 is very difficult to get used to as a user experience. Novel, fascinating, powerful, yes! But also minimal, impenetrable, and very very different from the UI you're used to as a Unix hacker.

\- nonexistent marketing

\- too hard to get into initially; I wish they had gone to a public source repository model earlier, although in all fairness the project predates a lot of this.

But, it was still an enormous success:

\- UTF8 came from Plan 9

\- Linux's clone syscall

\- /proc

\- numerous other minor things

The main thing I wish I saw more that was in Plan 9 was structured regular expressions. I'd love an awk based around them, or an ssam that didn't basically run sam on the file. The second thing I wish I saw more was Plan 9's per-process filesystem namespaces. Chroot and jail are crude hacks compared.

<comment><USER19> > \- UTF8 came from Plan 9

Not really, Ken Thompson certainly contributed to it, but they didn't invent it.

<comment><USER9> No, UTF-8 was invented by Ken Thompson. Source, by Rob Pike: <http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt>

Key quote: "Looking around at some UTF-8 background, I see the same incorrect story being repeated over and over. The incorrect version is: 1\. IBM designed UTF-8. 2\. Plan 9 implemented it. That's not true. UTF-8 was designed [by Ken Thompson], in front of my eyes, on a placemat in a New Jersey diner one night in September or so 1992."

</comment></comment></comment><comment><USER20> 1\. It's not marketed -- professionally or at a grassroots level.

2\. It's a research OS not necessarily meant for every day use.

<comment><USER21> I totally agree. From the one-off-not-quite-compatible license to no marketing from Lucent to no real niche to lets try Limbo, Plan 9 never got a firm base with marketing.

</comment></comment><comment><USER22> Howdy, I installed Plan 9 several years ago(close to 10, if I remember correctly). I thought it was interesting, but it had a few problems. 1. It was too hard to install. I figured it out, but it was difficult enough that I thought I would not be able to recommend it to many others, unless they were fairly advanced. 2. The supported hardware list was too small. Mostly, this was a problem with supported nics. On a system like Plan9, a system without a good NIC is pretty useless. 3. The community of users was too small. I did not find any other local users. I found a small community of online users, but they only seemed interested in using Plan9 to break into systems and that did not interest me. I should probably try it again, since many of these things could have improved. I have also used Inferno a bit on a prototype ATT phone and I would like to program that a bit. Linux ended up having most of what I wanted Plan9 for and that is probably why I have not tried it for so long.

</comment><comment><USER6> I earlier posted reasons why (IMO) Plan9 "failed" but will likely (in a new form) succeed on big compute clusters.

The other possible place for a big breakthrough is mobile. For example, if all of your "apps" are in Java and those apps hardly ever touch traditional unix system calls, it is easy to knock a Linux or Windows OS out from the bottom of the stack.

</comment><comment><USER23> Same reason the Hurd never materialized. Linux was good enough that nobody cared to put in the massive effort required to make the slightly better solution industry-strength. It's something like the death by a thousand cuts, only in this case, the thousand cuts are unsupported hardware and silly programs that don't have ports or package maintainers, but that people still want anyway. BSD gets away with being the unpopular but probably better alternative to Linux by a massive effort to port all linux software to it, and a great linux compatibility layer for things that aren't ported.

<comment><USER24> Hurd was never fully functional. It never worked well enough to have an opportunity to be rejected for being weird.

</comment></comment><comment><USER25> I think it is significant that both Unix itself and Linux were category killers. Unix succeeded because people kept going "Wow, there's nothing like this!" and writing in to get it, copying it passing it on to other people. When Linux took off, there was no Free-ly available Unix-like OS (at that time). Linux quickly gathered a critical mass of users who saw it as something like the answer to their prayers. I guess the strengths of Plan9 were not such as to create a new category for itself, and its flaws made it an unsuccessful competitor against existing Unix-like systems.

</comment><comment><USER26> I've worked with Plan9 and Inferno. I think they both failed for two reasons:

1\. lack of device drivers for commonly found hardware at the time.

2\. Ugly looking graphics and desktops and difficult (relative to what was widely used at the time) to use as well.

IBM's use of Plan9 with BlueGene uses the server side benefits so they need only a small number of custom device drivers and the GUI is not used at all.

</comment><comment><USER27> Similar situation to why weren't other featureful alternative OSs more popular? Like BeOS? Imagine how different today's world would be if Apple had bought BeOS instead of NeXTSTEP (which included Steve Jobs)? Often it's some large corporation's decisions that dictate what technology gets adopted, what fails.

<comment><USER28> Be did a couple of things that prevented BeOS from going anywhere.

One was basing the machine on PPC processors initially, because it limited their audience. I thought it was a cool idea, but wasn't willing to buy outdated hardware to get the OS. Mac users at the time could have simply acquired the OS and installed it, but the number of mac users willing to do that wouldn't ever be large.

One was not supporting IDE when they ported to x86. When they finally went after a large market, they made sure that hardly anyone in that market COULD use it. I had to do a lot of finagling with my computer in order to install BeOS on it.

AFAIK Apple actually DID try to buy Be before going after NeXT once they realized that Rhapsody simply wasn't going to happen. I've heard a number of stories regarding this, and I don't know which to believe; I was informed that the Be CEO rejected Apple's offer. If someone has better knowledge of that part of history than I and can confirm or correct me, that would be appreciated :)

<comment><USER29> Be definitely wasted a lot of time in strategic churn, porting from Hobbit to PowerPC, BeBox to Mac, PowerPC to x86, PCs to thin clients, etc. For the brief time that BeOS ran on Macs, the likely goal was not to get Mac users to switch to BeOS but to convince Apple to buy Be. I heard that Apple offered $75M for Be and JLG refused. (Some people assume that Apple offered the same amount for Be and NeXT, but that's pretty unlikely considering the difference in maturity.)

BTW, where you wrote Rhapsody you meant Copland. NeXTSTEP was renamed to Rhapsody (and then OS X) after Apple bought it.

<comment><USER28> Oops. I lost track of product names frequently, especially since there are so many ;)

You're probably also right about the reason for starting out with a PPC based system. I'd heard about a similarly sized offer for Be, as well as JLG's refusal.

There weren't a lot of realtime OS's out there, and still aren't -- BeOS could have been the next OS/2, only without IBM's marketing behind it. (Can anyone say, "Friendly fire?")

</comment></comment></comment></comment><comment><USER30> It's because Unix has become very popular and it is good enough for mainstream use despite its flaws. Plan 9 brings certain design improvements but they don't actually justify a need for replacement.

It's actually not that surprising since good design on its own is never a sufficient criteria for something to become mainstream.

</comment><comment><USER31> I use the wmii window manager which is based off some Plan9 principles. Surely you wouldn't bring it home to grandma, but for fast efficient use of screen space with a keyboard I think it's hard to beat.

</comment><comment><USER32> Glenda is super cute but did you try to use Plan9? I give it a small try last year and well... GNU/Linux is mainstream, FreeBSD is a really good derivative of Unix too, OpenBSD is great when we want to have a secure OS... NetBSD would probably run on my toaster... But Plan9? It have a cute mascot.

Oh and I really like its name and the "Plan 9 from User Space" thing, especially after having seen the fabulous movie! But I think of it only as a cool thing to know, never seriously think about using it in place of a GNU/Linux or a *BSD. (same thing for Open Solaris too in fact)

</comment><comment><USER33> One killer setup for Plan9 would be to package it up as a VM and distribute it. May be Amazon can pre-create some Plan9 EC2 images.

</comment><comment><USER34> Are you running it?

</comment><comment><USER35> Because worse is better.

<comment><USER36> Or because good enough is good enough.

<comment><USER37> Or Avoiding success at all costs...;)

</comment></comment></comment><comment><USER38> I've been a Plan9 user/dev since 2000. Have been to two of the IWP9 conferences - sadly I won't be going to Seattle for the 5th unless I score some big cash in the next few weeks - <http://iwp9.quanstro.net/>

* Licensing - Plan9 wasn't open when open was the in thing.

* No web browser - just as the web became a big thing, no web browser is a deathtrap.

* The gap is too great a leap - until the recent LinuxEMU almost _NONE_ of your fave apps were available - unless you _really_ like cmd line tools (I do :)

* Hard to justify in your organisation - when you're one of only 50 people in the world that know how to use an OS, making it part of your infrastructure is a huge risk.

That said, to suggest it is a failure is erroneous. We have at least one successful company using Plan9 in their hardware - Coraid. They have the commitment, income and a few of those 50 people to make it work for them. IBM also use it on Blue Gene and other super computers, as do Sandia National Labs, LANL and others around the world. It was also used at the Sydney Olympics to control the stadium lighting and Lucent use it in their cell phone masts in Real Time mode.

Come and chat to people in irc://irc.freenode.org/#plan9

Oh - there's also a fantastic port of many of the tools into Linux / BSD. <http://swtch.com/plan9port> I use them every day - Venti is particularly useful

<comment><USER39> Hey! I'll be at IWP9 5e this year if things go well. Fun to see another Plan 9 user on here. I'm an intern with Sandia Labs, working on my master's degree at the moment, so I've got this work I've been cooking up all ready for a Work In Progress report at IWP9.

To expand a bit, I think Plan 9 has potential in the world of scientific computing. There are a few things scientists expect on their supercomputers, and Plan 9 either has them or can have them without unreasonable effort. They include: MPI, Python (already available), Linux compatibility layer (exists), and FORTRAN 77 (this can happen if we reaallllly need it). Check out the HARE project, where Plan 9 was ported to the Blue Gene systems as part of the ongoing Fast-OS project, which aims to find a better OS for supercomputing. (Basically, Linux is too huge, whereas custom kernels are just too stripped down and customized. Plan 9 is small but general)

<comment><USER38> Ron's talks last year were fascinating. It's great to hear the truth behind the veil of the HPC world. That they run Linux but then use OSBypass becase the Linux kernel is too slow was a revelation, they don't shout that part too loud when gushing about Linux. The curried syscall system was enlightening.

<comment><USER39> Thank you, that was kinda my baby--Ron had the actual idea of course, but I did the implementation. It was really great how easy it was to do.

</comment></comment></comment></comment><comment><USER40> From the 9fans mailing list a while back, someone asked what the plan9 people at Google use:

<http://9fans.net/archive/2010/02/344>

and

<http://9fans.net/archive/2010/02/366>

</comment><comment><USER41> I used plan 9 for a while, and I really like it; but when I was looking to use a network filesystem I tried a 9p remote mount between two Linux servers over the internet. I was disappointed to find that it was much much slower and generally performed worse than sshfs, perhaps due to lack of caching and readahead. Perhaps there is some way to use 9fs more effectively with a caching / readahead layer, I guess it would be simple enough to implement such an intermediate server in plan 9.</comment>


Web Design Firm Tells You Why You Shouldn't Redesign Your Website - <AUTHOR> http://www.eurekasem.com.au/real-reason-shouldnt-redesign-website/

<comment><USER2> Beware, pop-over with no close button once you scroll down the page.</comment>


Show HN: FotoFox – save 20x photos and videos on your phone - <AUTHOR> http://www.fotofox.io

<comment><USER2> I wouldn't trust my files on your servers if you can't lock down a directory, [http://www.fotofox.io/assets/](http://www.fotofox.io/assets/)</comment>


7 Business Lessons: Game of Thrones Style - <AUTHOR> http://blog.pipesapp.com/business-lessons-gameofthrones-style/

<comment><USER2> The author misses the double-meaning of the phrase "a Lannister always pays their debts". At face value, it follows the finance meaning of debt. If a Lannister owes you money, you're likely to be repaid. Arguably, that is not the most significant meaning of the phrase though. When taken in the full context of the events portrayed in the story, the more important meaning of the phrase is that if you wrong a Lannister, they owe you a debt of retribution; which you are assured to get.

The phrase is, essentially, a thinly veiled threat.

The more sinister meaning is equally applicable to business. Your cohorts are far less likely to wrong you if they are certain that the debt of retribution will be repaid. You don't have to go to Tywin Lannister extents, but you should avoid being perceived as a push over.</comment>


You shouldn't turn off the lights for Earth Hour - <AUTHOR> https://birdeatsbug.com/blog/earth-hour <comment><USER2> Or "How the Earth Hour could collapse the power grid"

<comment><AUTHOR> Yeah, could work

</comment></comment><comment><USER3> Is the operation of the power grid also dependent on this source of the energy? e.g. coal vs. wind</comment>


A free web-based video game console to pass time during lockdown - <AUTHOR> http://www.airconsole.com/staysafe <comment><USER2> The controls on this look clever. Cool project!

</comment><comment><USER3> Looks super cool!</comment>


Cruel and Unusual: The Story of Leandro Andrade (2003) [pdf] - <AUTHOR> https://scholarship.law.duke.edu/cgi/viewcontent.cgi?httpsredir=1&article=2404&context=faculty_scholarship <comment><USER2> I couldn't read the whole PDF. It's just too depressing. The U.S. penal and justice system to me seems like a great big mess full of rage inducing injustices.

<comment><USER3> It only seems that way to you and other people who feel that way because you only hear about the times when the system fails. Not the vast majority of times when it works.

<comment><USER4> The vast majority of all criminal court cases end up in plea deals. That was never the norm prior to Prohibition, and, later, the drug war. Judges used to dislike plea deals. Now they need them in order to keep load down.

Plea deals are extremely coercive. It's all too easy for an innocent defendant with marginal resources to take a plea deal because the alternative is worse. Yes, plea deals are a cup half-empty/full thing, but all too often they are coercive rather than a good deal for a guilty defendant.

Lastly, whatever happened to "better ten guilty men go free than one innocent man be imprisoned"?? We absolutely should consider innocent people convictions as a metric that counts for ten times that of guilty people who got less (or no) time than they should have. Do you not agree?

<comment><USER3> I am in agreement with you. Luckily the majority of people convicted of crimes are actually guilty of what they're convicted of.

Now I don't believe people should be going to jail for petty drug offences, and that drugs in general should be decriminalized, so we can disagree that the laws being used to convict people should be changed, but the vast majority of people being convicted of breaking laws are actually breaking those laws.</comment></comment></comment></comment>


Ask HN: How do you avoid people distracting you at work? - <AUTHOR> I work as a developer at a large company in a large open office. We have many scrum teams and communication via Slack is normal. My coworkers frequently walk up to my desk to start conversations. I would like to encourage them to use Slack instead at certain times such as when I'm under pressure with a project but I'm not sure how to signal this to them. I have too many colleagues to simply ask them kindly not to distract me at certain times so asking the people around me not to distract me if I have headphones is ineffective.<p>Do you have any strategies signalling to your colleagues (many of whom you might not know) that you would prefer not to be distracted at certain times? <comment><USER2> I've tried and been unsuccessful. There's always that clueless employee that starts talking when my headphones are on. It may be a personal problem too, I really like helping.

actionable advice:

The adult: Use your words "I have my headphone on, that means please do not disturb." or make eye contact slowly shake your head 'no' It's especially difficult when the person is a repeat offender. But don't forget you would be helping not just yourself, but them AND all the people they might bother in the future. You might even need to go to your lead or supervisor or HR. Don't dismiss your need to get your work done. They're wasting your time and the company's money.

The easy: Don't respond. That's kinda a lame move, but oh well.

The difficult: Put a red light on your monitor. Turn it on when you're working, refuse to answer any questions until your done. Don't do this.

<comment><USER3> I have a few coworkers that don't get the whole "headphones on, he's busy" concept. In some cases, they just start talking as if the headphones aren't even there. Sometimes, I pretend I can't see them talking and then after a short time, I look up, remove the headphones and say, "Sorry, were you talking to me? I was focused on something."

They usually get the message and apologize, but I still don't get it. I mean, emergencies aside, send me an email, a text or any other notification you can think of and let me get back to you.

</comment></comment><comment><USER4> If you can communicate it to someone that manages your team, or the person that manages your manager, you should. They can make it clear that interruptions should only happen on a need to happen basis.

Otherwise, if you are in an environment where people higher up will not empathize and tell you that this just makes you guys more creative:

a) Look for another job b) In the meantime, print out a quirky message on a piece of paper, to appear friendlier, asking the potential interrupter whether what they need is urgent, and if it's not, to try hitting you on slack if you have your headphones on (or in general even). It should work.

</comment><comment><USER5> A lot of my colleagues dont use headphones, so it is kinda hard to send the message headphones == do not disturb. From the other side, I work in Germany, so I just need to say "Sorry, I am busy!" and continue to do my work. It works great, and I don't even feel bad about being rude or misinterpreted (which was something that used to stay in the back of my head after not helping a peer.)

</comment><comment><USER6> A lot of offices have a culture where headphones-on means "do not disturb" or "slack to see if it's ok before disturbing".

You don't even have to play music if you don't want to - just put a pair of cheap headphones on your head.

<comment><USER7> This is my advice too - I usually don't play music in my headphones, but then I can ignore people when they're talking to me for the first couple of seconds, and then i can look up and they have to start over. It's mean, but effective.

</comment></comment><comment><USER8> To piggyback on what others have said, if you're in a certain type of company then interrupting you to talk is an important social status symbol. It's an implicit (and sometimes explicit) signal that their status is greater than yours, and your submission to them is more important than the value you create for the company.

If this is the case, I'd highly recommend finding a place that values your productivity.

<comment><USER9> Isn't ignoring someone who wants your help showing that your status is greater than theirs?

</comment></comment><comment><USER10> Why don't you bring this up in your team/company meetings? If you are facing it then be assured that many others are also experiencing the same. It's impacting the productivity of your team. And it can't be solved in isolation.

Together you guys can decide what works best for your environment. It could be headphones, no-disturbance period or the opposite (office hours / collaboration period).

</comment><comment><USER11> If headphones don't do the trick, and you want to stop people before they actually bother you, have you tried just putting a sign on your desk or the back of your chair that says not to bother you?

</comment><comment><USER12> Sometimes I will take my headphones off and say, "Hey sorry, I'm deep into X right now — Can I grab you [in 10 min | when I'm done]?"

</comment><comment><USER13> Try DND Shades ([http://dndshades.com](http://dndshades.com)). Much more explicit than headphones.

</comment><comment><USER14> Here's what I do: "Sorry I'm in the middle of something, can I get back to you later?"

</comment><comment><USER15> h e a d p h o n e s</comment>


New tools to make your job search simpler - <AUTHOR> https://blog.google/products/search/new-tools-make-your-job-search-simpler/ <comment><USER2> Related: Job Seekers: Three Powerful Ideas to Amp-up your search efforts today… > [https://medium.com/@JSeymourATL/job-seekers-three- powerful-i...](https://medium.com/@JSeymourATL/job-seekers-three-powerful- ideas-to-amp-up-your-search-efforts-today-91dc3e9b6033)</comment>


Daring Fireball: The iPhone 3G - <AUTHOR> http://daringfireball.net/2008/10/iphone_3g <comment><USER2> That's a deep throating if I've ever seen one.

I posted this before, but I'll do it again:

Weird, I use my iPhone for everything but a phone, because, frankly, it sucks as a phone. Which is good, because I let it disrupt me less and am less likely to disrupt other people because I don't want to wait for it to unfreeze and then another 30 seconds it takes me to scroll through my contacts list and then thumb the fucking thing and then click on call.

And, shit, I don't even use it for email because it sucks for that too. I can't search. I have 5 email accounts for various things and I have to click 15 times to check them all, instead of a single view like the blackberry. Oh and I can't search. I mentioned that. Did I mention that? Yeah, I can't search. And when I click on a message I have to wait for the fucking webkit view to load before I can read it. I can't copy and paste addresses, I can't forward emails as sms's, I can't save attachments. SO awesome.

So yeah I use it for everything but email and the phone. And maybe SMS messaging too I do a lot less of because it's another slow cumbersome process that zaps the joy out of semi-realtime conversation. I love it when it craps out, and how it can't send in the background and those wonderfully stupid chat bubbles. I am not 12 years old.

So I don't really use it for anything other than browsing the web, tracking poker stats and playing Wurdle. I love Wurdle. I can play it until my thumbs cramp. I hope those guys make millions.

So yeah the iphone is the greatest piece of something alright.

<comment><USER3> The problem with Apple making only one of them is that they can only have one priority list, while the myriad of Android devs can have as many as users do. iPhone's list is something like:

1\. Web Browsing 2\. Music/video 3\. Games 4\. Email/sms 5\. Phone

That's almost the exact opposite of every corporate user, and most teenagers.

It will be interesting to see if they ever release a second model, the way they eventually put out different lines of iPods. Maybe something bigger and less flashy, but with a keypad and way better voice. I won't hold my breath, but it might work.

</comment></comment><comment><USER3> Wow, I've never actually seen someone fellate a phone before.

<comment><USER4> He should use an iPhone to record a video of that... oh wait...

</comment></comment><comment><USER5> Why are people so enamoured with this fawning sycophant?

<comment><USER6> I generally like Gruber's writing, but this piece was just drivel. It read more like "I've barely used any other smartphones!" than "the iPhone is great compared to other smartphones".

</comment></comment><comment><USER7> It should have just stopped after the 6th paragraph.

<comment><USER8> Indeed. One of the features he hypes most

" _If Apple can build a feature like this into the iPhone itself, it will be a smash hit feature, and, if it were something that only worked with Mac OS X, yet another impetus for iPhone/iPod users to switch from Windows._ "

is 3G tethering, deliberately removed from the App Store by Apple, and already available to Windows, Linux and OS X users of any old free-on-contract 3G Nokia.

Even Ubuntu (in 8.10) includes support for 3G modems, which should give you some idea how old hat they are :)

</comment></comment><comment><USER9> I love it. And _i_ love my _Phone_! :)</comment>


A survey of recent iOS kernel exploits - <AUTHOR> https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html <comment><USER2> For people who think that there is far more CVE on iOS than Android (based on this article): [https://www.cvedetails.com/top-50-products.php?year=2019](https://www.cvedetails.com/top-50-products.php?year=2019)

And it's for 2019 _only_

<comment><USER3> Number of CVEs in general is a fairly poor way to evaluate the security of a platform.

<comment><USER4> Agreed. In other comments here however, there are folks arguing that this shows iOS both is/isn't secure and that Project Zero has a hidden goal of making Apple look bad. I think the poster above is trying to respond/provide context to that.

<comment><USER5> Apple provides security updates longer than Android though.

One could argue being able to own a phone for 5 years and receive security updates for a higher up front cost is preferable to buying a new phone every two years.

To be blunt, that policy + the fact Apple has no business units actively incentivized to invade my privacy (no targeted marketing dept) makes me choose iOS, even if it's "less free".

My phone is home to my most intimate conversations, I need to know it's secure for the long haul.

<comment><USER4> I agree with you, and that's why I have the phone that I do. There are clear tradeoffs between the two ecosystems. My comment was providing context to the one above it.

</comment></comment></comment></comment></comment><comment><USER6> Great summary list near end of article of the various mitigations used by iOS - there is quite a few hardware protections implemented within the processors themselves.

Android is less of a monoculture, but also has less opportunity to tune the processor to include strong hardware mitigations against whole classes of vulnerabilities.

<comment><USER7> While iOS seems to pioneer every mitigation technique ever described in the literature, they also shipped ancient versions of C image parsing libs (OpenEXR), have an endless stream of remote code execution vulnerabilities from their peculiar serialization schemes and all the other issues you would expect from the use of native ObjC.

Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.

<comment><USER5> >Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.

As a practical matter, doesn't this mean if I'm confident in my ability to avoid phishing messages, iOS is better?

Anything that "roots" a phone can also run roughshod, turn on my mic, grab signal messages stored locally, etc, correct?

What I'm getting at is a phone in a walled garden + a laptop that's open source might be the best way to get the security of the walled garden _and_ the utility of open source.

<comment><USER8> "confident in my ability to avoid phishing messages" is not a good way for security.

<comment><USER5> I literally designed antiphishing trainings.

I also have Firefox containers for important things like banking - a phishing url from my email will not open in the correct container. Huge red flag.

</comment></comment></comment></comment></comment><comment><USER9> Hoping to see such a list for Android too. I don't see one right now. [1] Some kind of comparison between iOS and Android on the kinds of issues and underlying causes would also be interesting.

[1]: [https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot....](https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot.com+android+kernel)

<comment><USER10> I really appreciate and enjoy the work done by Project Zero.

But, it often does feel like it could be retitled Project Schadenfreude. This particular post almost feels timed specifically for release right before WWDC.

<comment><USER11> They're doing Apple a huge favor by discovering these bugs. They're doing the security community a huge favor by publishing blog posts about them for others to learn from. They also do plenty of Android research, although iOS is a higher priority since most security-conscious people use iOS (including the researchers themselves). This is not a hit piece on Apple.

<comment><USER12> I'm not sure how this argument makes sense. Most _people_ use Android. I don't see any evidence that supports the claim that most "security-conscious" people use iOS.

If it is somehow meaningful to make that claim, then it is all the _more_ important for project zero to focus on Android, since people who are not security conscious are less likely to practice other forms of security.

Project zero simply doesn't seem to publish these pieces about Android at the same rate they do about iOS. Perhaps this is unintentional.

<comment><USER4> I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: [https://bugs.chromium.org/p/project- zero/issues/list](https://bugs.chromium.org/p/project-zero/issues/list)

For all issues, including closed:

product=Android returns 81 results

product=iOS returns 58

vendor=Apple returns 380

vendor=Google returns 145 (bugs in Samsung's Android kernel,etc. are tracked separately)

vendor=Linux return 54

To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products (Google lacks a desktop OS and an iMessage equivalent, for example), and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.

<comment><USER13> > Google lacks a desktop OS and an iMessage equivalent, for example

Nitpicking, but Chrome OS is a desktop OS, and Google has had at least 7 things similar to iMessage.

On topic, fron my perspective when I was working somewhere that got bug reports from project zero, it was great. I mean, not great that we had the bug they found first, or the follow-up bug they found after we fixed that one; but great that they were clear problems that we could solve. If we didn't want to be written up, we could have done better to begin with, and taken more care in looking around when the first bug was reported.

<comment><USER4> > Chrome OS

Is Chrome OS sufficiently unique enough from Linux to be its own category (genuinely asking)? I was aware of it when I made the original comment, but considered it more a subset of Linux, in that most major kernel security bugs would be shared.

Also, what are you considering similar to iMessage? My view is that iMessage presents its own unique & powerful attack surface that hangouts/etc dont have. Maybe RCS?

<comment><USER13> I think Chrome OS at least has a unique libc and GUI stack versus normal desktop Linux distributions? And there's certainly room for errors in their updater stack and all that.

gChat, Allo, Duo, SMS (whatever it's called today), Hangouts, Meet, ??? They're all relatively similar, send messages including media (remember stagefright)

<comment><USER4> > gChat, Allo, Duo, SMS (whatever it's called today), Hangouts, Meet, ??? > They're all relatively similar, send messages including media (remember > stagefright)

Most of those have a much more limited attack surface than iMessage, at least in my understanding. SMS is shared and doesn't try to do what iMessage does, thus the issues

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Amazing how something marketed as "secure by design" is, in fact, designed with the same issues as other competitive operating systems.

[https://www.apple.com/business/docs/site/AAW_Platform_Securi...](https://www.apple.com/business/docs/site/AAW_Platform_Security.pdf)

<comment><USER3> Rather than responding to this again, I'll let the responses you got the other times you asked this do the talking: [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22secure%20by%20design%22%20fortran77&sort=byPopularity&type=comment)

</comment></comment><comment><USER15> Looking the bottom part, is APRR the only mitigation exclusive to Apples own CPUs?

Also, is trustzone not available on these?

<comment><USER16> There's no trustzone, no, but boot is completely verified in much stronger ways. Software updates are uniquely signed per device, per execution to prevent downgrade attacks.

<comment><USER15> This confused me.

How does these unique signatures work and how does it improve boot security?

<comment><USER17> IIRC the general idea is that the pin code or password is required to be entered when an update is requested, which unlocks a key pair. The public key is included in the update request, which is then sent to Apple. Apple sends back a download that is signed in a way that the firmware can verify, and Apple guarantees never to send another download in response to that exact request. This protection also relies on the secure enclave never authorizing the installation of an unsigned OS update.

<comment><USER18> > Apple sends back a download that is signed in a way that the firmware can > verify, and Apple guarantees never to send another download in response to > that exact request.

Interesting! Thank you for the detailed explanation.

</comment></comment></comment></comment></comment><comment><USER19> Bookmarked for anytime someone tells me Apple products are secure.

Marketing doesn't line up with reality.

Not that those who parrot the marketing would be convinced with evidence.

<comment><USER20> So according to this article those of us on iOS 13.x (93% of the installed base) used to have one vulnerability, which we got patched through auto- updates 8 months ago. I'm quaking in my boots.

I hope you remember to point out the historical nature of this when you pass on the link.

<comment> yjftsjthsd-h In fairness, the question is less "how many vulns does this exact device have so far" and more "how many vulns are likely to occur for this device total", in which case this article could be evidence that the last few versions of iOS have each had their share, and therefore it is reasonable to extrapolate that to expect a handful of issues on _this_ version. Now the first obvious catch is that you can't necessarily accurately project the past into the future; if most of these are the result of some underlying design strategy that Apple has stopped doing, then the exploits would dry up. On the other hand, of course, they could start shipping some new technology that turns out to introduce more vulns (not likely, but it could happen).

Of course, I'm pretty sure the same list of exploits per-version of Android would be _much_ longer, so if anything this list, if complete, really does paint iOS in a very good light.</comment></comment></comment>


It's hard work printing nothing - <AUTHOR> http://www.tedunangst.com/flak/post/its-hard-work-printing-nothing <comment><USER2> The more I see of what goes on under the covers, the more surprised I am that anything works at all. As an example, every gtk+ program I run spews thousands of errors to the console. Why? Are they bad? The programs seem to run anyway, never crashing more than one would expect. So … why the console spam?

<comment><USER3> I think not a single actual application is completely well formed. They all work on luck. Especially in the embedded world. Btw, my android just rebooted.

<comment><USER4> "In the embedded world" covers a huge area, including mission-critical avionics code, which likely has much higher safety standard than, say, Android.

<comment><USER5> Although from hearing about the Apollo Guidance Computer, it's just as much of a miracle they were able to get it to work without any debugging or compilers, with basically one shot to write the program to ROM.

<comment><USER6> Well they put in an effort of 1400 man years for just the software. They even built an interpreter, because (flight/trajectory) requirements were changing all the time.

Also: "The highest level of testing was performed with a high fidelity digital simulation of the computer, spacecraft hardware, and mission environment."

[http://klabs.org/history/history_docs/mit_docs/1711.pdf](http://klabs.org/history/history_docs/mit_docs/1711.pdf)

</comment></comment></comment></comment></comment><comment><USER7> I love the dry understated link to PHK's [http://queue.acm.org/detail.cfm?id=2349257](http://queue.acm.org/detail.cfm?id=2349257) there.

<comment><USER8> > Here is one example of an ironic piece of waste: Sam Leffler's > graphics/libtiff is one of the 122 packages on the road to www/firefox, yet > the resulting Firefox browser does not render TIFF images. For reasons I > have not tried to uncover, 10 of the 122 packages need Perl and seven need > Python; one of them, devel/glib20, needs both languages for reasons I cannot > even imagine.

This is a better read than the linked article, really.

<comment><USER9> That's rich coming from PHK, whose software requires a full C compiler as a _runtime_ dependency.

The reason Firefox pulls libtiff is simply because it uses a generic image manipulation library (libgdk-pixbuf), which in my system it's also used by many other applications - which do require TIFF support. I guess if you have a desktop with only FF installed that may be a waste, but how many people really have FF and not any kind of image viewer installed?

<comment><USER10> That's a very sensible requirement. It says in the docs exactly what they use it for. Not like they put in a bunch of other dependencies and some 3rd degree dependency pulled in a C compiler.

<comment><USER9> The C compiler in question pulls in a bunch of libraries for dealing with math problems (libgmp, libisl, libmpc, libmpfr) and zlib. Does their config language need support for "integer points bounded by linear constraints"? And why are they pulling zlib, when they also bundle it?

I don't see the difference. Instead of including a specific compiler for their needs, they are bazaar-ing a full generic C compiler (along with irrelevant libraries) just like Mozilla is doing with a generic image manipulation library, which pulls libtiff since many packages that also use it need TIFF support.

<comment><USER10> I mean I guess they could bundle tiny C compiler but your point about the C compiler is more about how modern distributions bundle and distribute compilers more than about varnish depending on a C compiler. You can choose to install the smallest subset of the libraries required to enable varnish to perform its job. Not like varnish explicitly requires libgmp to do bignum arithmetic. It's how your distribution of choice installs gcc and pulls in all the stuff with it.

<comment><USER9> No, gcc _requires_ libgmp, it's not just a choice by the distribution. But even if it was, that is exactly why Firefox pulls libtiff - it's not like it explicitly requires the library, it's just how the distribution installs libgdk-pixbuf. Yet PHK uses that as an example of the waste created by the development model.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> _There's an argument to be made that silly error messages are better than crashing browsers_

There's an argument, but it's a really lousy one. If you're passing NULL as a string to printf, _your code is broken_. A crash which results in someone tracking down and fixing the bug is far better than _quietly doing something which is 100% guaranteed to be wrong_.

<comment><USER12> > _" A crash which results in someone tracking down and fixing the bug is far > better than quietly doing something which is 100% guaranteed to be wrong."_

Not necessarily. Wrong is relative and can have either small or large costs, and crashing also has a cost to the user (and to the developers if they lose users.)

As an example, I play a very old video game (Descent). One of the major problems with one of the modern source ports is that the game crashed under certain conditions -- like if it received a malformed data packet. This is a game that's already fairly tolerant to lost data, so just dropping a bad packet is an acceptable result. By comparison, crashing in the middle of a competitive match is a much worse result, because it affects things like momentum and where various powerups have been left around the map.

It would be great to fix the bug that was resulting in malformed packets -- but the cost of directly affecting a high-stakes match is not worth it. I'd rather tolerate a fraction of a percent of lost data every game for the next 20 years than _ever_ have a high-stakes match where the result was tainted by a badly-timed crash.

<comment><USER13> If it were possible to gain an advantage in a competitive match by having your system deliberately drop a packet, the game would quickly become impossible to play competitively - that kind of cheating would be basically impossible to detect because there's no way to tell it apart from a genuine bad internet connection. If you've carefully thought through what the game should do when a packet is malformed that's one thing, but if you haven't thought about it then cleanly crashing is probably the best option.

<comment><USER14> That isn't true at all: Often competitive players are required to use the tournament organizer's hardware anyways.

And often competitive players form groups to play in, so everybody knows each other even while practicing.

You'd probably want to be on a LAN to minimize the risk of this happening accidentally.

So in practice, I don't think it would matter too much even if money was on the line. You would just have to take appropriate precautions, and watch to disqualify people for cheating.

</comment></comment></comment></comment><comment><USER10> I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled the problem elsewhere. These people will find a way to introduce 100+ dependencies on other services.

<comment><USER15> > Currently working on a project with 200+ requirements in requirements.txt > and growing.

That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.

<comment><USER16> Eh, in Ruby, just installing Rails is like 80 dependencies. Would be surprised if Django wasn't 40+

<comment><USER17> Django itself has no requirements besides the standard library:

        % pip freeze
        Django==1.10

That's after a pip install in a fresh virtual environment.

<comment><USER18> Rails itself is broken up into smaller packages, so you can only load parts of Rails if you want. Very few apps actually do. (and that's only like 8 of the 80)

</comment></comment></comment></comment></comment><comment><USER19> Semi relevant, I just spent the last two hours getting an ancient machine printing to modern copier.

<comment><USER20> I would love to hear the story if you have the inclination to go into details.

</comment></comment><comment><USER21> Could someone give an ELI5 on this? I know talloc's snprintf test is broken, but I'm not sure what the point is.

</comment><comment><USER22> I actually consider it a good engineering decision printing "(null)" when the 0 pointer is passed to the printing function.

</comment><comment><USER23> Perhaps exception handlers should run inside a sandbox by default, because we know that exceptions are usually not well tested.

<comment><USER24> So programs should just fail silently?

<comment><USER23> The sandbox could complain if the exception handler fails.</comment></comment></comment>


Ask HN: What testing tools do you use? - <AUTHOR> <comment><USER2> Firefox's PixelPerfect for Manual Visual Testing. There are some great tools for grunt to do automated visual testing[0] — and CSS unit tests are viable strategies[1].

Jasmine specs in Karma/Protractor for overall functional testing: of code/calls/functional groups, of functional flows, and of behavior specifications: so, Unit Testing, E2E testing, Behavior Testing (BDD). Search for headless versions of the browsers you're interested in, and integrate into grunt — but here's a Stack thread on mobile: [http://stackoverflow.com/questions/464089/simulators- emulato...](http://stackoverflow.com/questions/464089/simulators-emulators- for-mobile-browser-testing?rq=1)

There's a great tool in Firefox to record actions in Selenium, though WebDriver probably isn't adequate for tech like AngularJS templates or even Semantic HTML (which is a moving target, since W3C Standards enable richly complex "pears"[2]).

Semantics[3]; use Fangs-to-Audio[4] to get a "subjective" feel for how your copy sounds to people on screen-readers/assistive tech/devices. Use [http://wave.webaim.org/](http://wave.webaim.org/).

Follow schema.org as a normative guide to what Search Engines will likely look for. You can probably automate diffs between semantic markup structures and Web Scrape schema.org to determine how "meaningful" your markup is overall.

As always, believe in Unicorns[5].

[0]: [https://www.npmjs.org/package/grunt-screenshot- diff](https://www.npmjs.org/package/grunt-screenshot-diff)

[1]: [http://prezi.com/piifihs2ohet/test-driven- css/](http://prezi.com/piifihs2ohet/test-driven-css/)

[2]: [http://pea.rs/](http://pea.rs/)

[3]: [http://www.w3.org/2002/08/extract- semantic](http://www.w3.org/2002/08/extract-semantic)

[4]: [https://addons.mozilla.org/en-US/firefox/addon/fangs- screen-...](https://addons.mozilla.org/en-US/firefox/addon/fangs-screen- reader-emulator/)

[5]: [http://validator.w3.org/unicorn/](http://validator.w3.org/unicorn/)

</comment><comment><USER3> In terms of Performance Testing, most of the tools out there are either expensive or awful. However a couple of weeks ago, HP released a community edition of its flagship LoadRunner 12. It's basically the full LoadRunner product for up to 50 concurrent users (plenty for most startups).

</comment><comment><USER4> mainly using [http://casperjs.org/](http://casperjs.org/) to do all my high level testing.

as to services, recently started moving to [https://www.codeship.io/](https://www.codeship.io/) for continuous integration testing. though I love it it doesn't 100% cut it for me though as I have some dependencies on Windows, unfortunately.</comment>


Richard Feynman's Love Letter to His Wife Sixteen Months After Her Death - <AUTHOR> http://www.farnamstreetblog.com/2013/08/richard-feynmans-love-letter-to-his-wife-sixteen-months-after-her-death/

<comment><USER2> "PS Please excuse my not mailing this — but I don't know your new address."

I like that.</comment>


The Inuit don't shout at their children – so why do we? - <AUTHOR> https://www.theguardian.com/lifeandstyle/2019/may/12/the-inuit-dont-shout-at-their-children-so-why-do-we <comment><USER2> My policy about kids is to never shout unless it's to protect life and limb. If they are about to feed the dog a chocolate bar or walk across the street into traffic then shout away. Same with my animals.

If you shout about everything then they will just learn to ignore you when you yell. Worse than that, they will learn to shout when they are upset too. Then you just end up as two people screaming at each other and nothing is accomplished.

</comment><comment><USER3> I'm part Eskimo and grew up I. Alaska. My mom yelled at me, this is a different time:place.

</comment><comment><USER4> I don't shout at my kids, pretty much ever.

There's also no punishment, no time out, no naughty corner.

They rarely get in trouble with me either.

No punishment, just understanding and explanations.

If they do something that really bothers me I ask myself if I've have ever properly explained to them why that behavior isn't OK.

I once got very angry and shouted at one of my kids and shook my finger at him but it was all an act. He crossed the road without looking and I wanted after a lifetime of me not getting angry, to badly shock him, to really frighten him, to slam home the importance of looking when crossing the road.

</comment><comment><USER5> Previously : [https://news.ycombinator.com/item?id=19396563](https://news.ycombinator.com/item?id=19396563)</comment>


Show HN: Podfio – Netflix of Podcasts - <AUTHOR> https://podfio.com <comment><AUTHOR> Founder here.

This is the prototype that I have been working on. We applied for YC W2018 batch.

Any comments/suggestions would be helpful.

<comment><USER2> To me, the reference to Netflix seems like something that may be problematic in terms of what it communicates to investors with an historic perspective regarding technology companies. The technology problem Netflix solved to become a successful startup was bandwidth. It did so by mailing DVD's using 'snail mail' and the value proposition it offered consumers was unlimited DVD rental for a flat fee. It's competitive advantages were convenience for a specific class of customers -- those with internet access to view the catalog and comfort using the web -- and the lower overhead of a website versus retail locations for video rental stores. One enabling technology was DVD's which could be mailed for less cost than VHS tapes and were less subject to physical damage and provided higher quality (for which retail locations initially charged a premium despite requiring less shelf space). There's nothing on the web page that conveys those kinds of similarities to Netflix...instead from a business standpoint I wondered how it would compete with iTunes. From a personal standpoint, all I want in terms of podcasts is an interface to handle whatever URL I throw at it.

In terms of the podcast industry, I get the sense that there may be plays in the B2B end from listening to Jeff Meyerson's _Software Engineering Daily_. But I am not sure that exclusive content is part of it...I wonder why a podcaster would want to be exclusively on Podfino versus iTunes? Exclusive content requires a two sided marketplace and the moves by Netflix and Amazon (and HBO years ago) came long after they had established large subscriber bases for third party content.

All that of course is absent knowledge about "What problem this solves" or why it will destroy iTunes.

Good luck.

<comment><AUTHOR> Thank you for your feedback!</comment></comment></comment>


Teaser video for my new startup?  - <AUTHOR> http://www.youtube.com/watch?v=OqgXD0fPRBo&feature=player_embedded#t=0 Any feedback is appreciated. Thanks <comment><USER2> Your voiceover artist sounds like she's on the verge of a hysterical breakdown.

What does she find so funny about "what if there was a better way?"

</comment><comment><USER3> Technically this is an app, not a startup (from the looks of things.

Voice is great, if a little forced at points, she can sound a little TOO enthused.

Animation was nice, obviously not top of the line, but professional-grade nonetheless.

Fonts could do with some work, you use at least two (ignoring Votechat brand font) once looked like Times New Roman, the other like Comic Sans, neither of which are that great.

App concept is simple, but perhaps not too clearly explained. The algorithm explanation left me scratching my head as 'number of people' / 'number of ideas = 'votechat' makes no sense.

I was also left wondering about your first example of a user case: several ideas. Wouldn't it be best to have people rank their preference and have a simple algorithm work out the activity/idea with the highest combined popularity?

A situation where 5 out of 8 people want to go paintballing, but 3 really don't, but they'd all like to go to the cinema would be problematic for your app. If the 5 vote for their paintballing over the cinema, 3 people will be left out, or unhappy to attend, whereas with a ranking method, you may have all 8 doing something they like, together.

<comment><AUTHOR> Thanks for the feedback. What do you think of our site ? ([http://www.votechat.me/](http://www.votechat.me/))

<comment><USER3> Site is very clean and fresh, nice job. Your colour palette is perhaps too simple, most companies go for a a few shades of three complementing colours.

Green is also a colour closely associated with greed and money, or nature and freshness. Neither pair of concepts fit well with your product really.

Content seems well written and concise. You mention an Android version which I don't think the video did.

The last section at the bottom of the page is rendering strangely in Chrome (but not Firefox). Every 'e' has a very heavy weighting on the middle bar, it looks thicker and so every 'e' stands out in that final description beneath the subscription box.</comment></comment></comment>


Dark Packets and the End of Network Scaling - <AUTHOR> https://docs.google.com/a/ancsconf.org/viewer?a=v&pid=sites&srcid=YW5jc2NvbmYub3JnfHd3d3xneDo0OTM2MTM3MGEzYjAxODUy <comment><AUTHOR> Paper: [http://cseweb.ucsd.edu/~gmporter/papers/darkpackets- ancs18.p...](http://cseweb.ucsd.edu/~gmporter/papers/darkpackets-ancs18.pdf)</comment>


Show HN: FollowWWW - a point and click web scraper (early beta) - <AUTHOR> http://www.followwww.com

<comment><USER2> Is it currently working? I tried a simple URL (below) and it's said "Loading" for quite a while:

<https://www.google.com/search?q=test>

Looks interesting though!

<comment><USER2> Ah - based on Chrome Web Inspector console, looks like it's trying to load <http://192.168.2.99:3000> which surely doesn't exist on my network.

<comment><AUTHOR> Sorry about that, missed a config param when transferring to the host. Should be working now.</comment></comment></comment>


Ask HN: End-to-end voice encryption AD/DA-hardware via 3.5-mm jack - <AUTHOR>

Since you cannot trust the hardware of any mobile phone anymore and no apps running inside them, I think the only way to ensure not being wiretapped would be to do the encryption outside of the mobile phone.
Would it be possible to establish a connection between two external AD/DA devices which you would plug in to the normal 3.5-mm headphone minijack, and let them do a handshake, much like an old fashioned modem, and then exchange RSA key pairs, and then encrypt the voice data over this connection?
The quality would of course not be as good, but maybe it would suffice? What bit rate would be possible to achieve and how would one design such a thing?
I'm thinking to start an open-source project where both the hardware and the software would be made open-source so people could build their own devices, and communicate securely with each other as long as all devices built share the same protocol.
Would it be possible to reuse some modem chips for this purpose?
Thanks to using the standard 3.5-mm headphone minijack, the device would work with just any phone, tablet or computer.
Is this a crazy impossible idea or could it work? <comment><USER2> It could work, though you would want to do some trial and error with different algorithms; in particular, you'd want to ensure that the compression doesn't screen out the quality of the call.

It would not be a trivial problem to solve, as these compression technologies are designed to be used for standard speech patterns, not (to the outside observer) garbled speech patterns. They normally do an amazing amount of compression while still sounding largely unmodified to your ear.

I'd make an encryption algorithm with a passkey that is handkeyed into both adapters, breaks every 100ms of speech into 10ms pieces, and reorders them according to the algorithm. Certain parts of speech would probably still get muddied by the time they were passed in and out of compression.

I'm sure someone's already successfully tried it and you can buy their wares somewhere on the internet (maybe with a pit stop at a certain place on their way to you).

</comment><comment><AUTHOR> The alternative would be to build an entire phone, like the Blackphone, but that seems like a hassle and then you can't use your favourite mobile brand, whatever that might be.

For any end-to-end encryption project to succeed, it would need to be all of the following: a) very cheap b) open-source hardware + software + PCB layout c) compatible with all existing mobile phones d) easy to build your self using standard components

</comment><comment><USER3> Have you heard of PGPfone?

[http://en.m.wikipedia.org/wiki/PGPfone](http://en.m.wikipedia.org/wiki/PGPfone)

<comment><AUTHOR> Looks like it's not maintained anymore, but could be a start for at least the software part of the project. The hardware is probably the most tricky part in this project. Any such projects out there?</comment></comment>


Uber campaign about Oregon ridesharing legislation - <AUTHOR> https://action.uber.org/oregon/

<comment><AUTHOR> I'm disappointed that the Uber page doesn't actually link to the bills in question: [https://olis.leg.state.or.us/liz/2015R1/Measures/Overview/HB...](https://olis.leg.state.or.us/liz/2015R1/Measures/Overview/HB2237) and [https://olis.leg.state.or.us/liz/2015R1/Measures/Overview/HB...](https://olis.leg.state.or.us/liz/2015R1/Measures/Overview/HB2995) .

Reading the two measures, though, this seems ridiculous. There are already laws about driving without insurance; drivers, whether commercial or not, already must have insurance to drive. What business is it to the state of Oregon whether that insurance is provided by the ridesharing company or the driver, as long as at least one of them have it?

Doubly so because the text of the measures explicitly includes companies like Uber ("engaged in the business of providing for-hire transportation by means of mobile application software") while excluding taxis and buses ("(b) "Transportation network company" does not include a legal entity that is qualified to do business in this state and: (A) That provides taxicab services; (B) That is engaged in the business of providing transportation along fixed routes or at regular intervals;". Even if this were a reasonable step to take for some other reason, it's entirely unreasonable to target specific companies while giving others a free pass.

Now, on the other hand, if the targeting were dropped, there is _one_ useful item in the legislation that seems useful based on issues ridesharing drivers have faced elsewhere: ensuring that the _owner 's_ insurance policy can't try to deny coverage to the owner when they're driving privately, just because they also drive for a ridesharing service. That still seems like a matter to be settled between the owners and their insurance companies, not a matter for legislation, but it's at least trying to address a real issue.</comment>