Linux kernel: multiple x86_64 vulnerabilities - <AUTHOR> http://seclists.org/oss-sec/2014/q4/1052 <comment><USER2> > This is likely to be easy to exploit for privilege escalation, except on > systems with SMAP or UDEREF

Another reminder why everyone should be using [https://grsecurity.net](https://grsecurity.net) which provides these mitigations to the Linux kernel via patches. GRSecurity has had SMAP aka KERNEXEC for a long time as well as UDEREF [https://grsecurity.net/~spender/uderef.txt](https://grsecurity.net/~spender/uderef.txt)

If you keep any sensitive data on a Linux server you should seriously consider grsec.

Even last week there was an ASLR bypass posted on OSS-security which of-course grsec already protected you against [http://seclists.org/oss- sec/2014/q4/908](http://seclists.org/oss-sec/2014/q4/908)

There is a lot of drama around the fact Linux core devs don't adopt these patches by default. But regardless Linux is pretty insecure by default and grsec makes privesc via various classes of exploits significantly harder.

<comment><USER3> > There is a lot of drama around the fact Linux core devs don't adopt these > patches by default.

What is the main cause of resistance for implementing these fixes? It worries me that they haven't put forth the effort to do so yet.

<comment><USER2> Daniel Micay who works on security with Arch Linux explains why GRSecurity hasn't been upstreamed here: [http://article.gmane.org/gmane.comp.security.oss.general/150...](http://article.gmane.org/gmane.comp.security.oss.general/15054)

And you can see Greg K H (a linux core dev) snarky reply here: [http://article.gmane.org/gmane.comp.security.oss.general/150...](http://article.gmane.org/gmane.comp.security.oss.general/15056)

Basically a few people have tried in the past but Linux core devs are against large patches. And if you look at old threads [1] where people have attempted to break it up into small patches the core devs have been disinterested.

Just to be clear we're talking about many 2003-era exploit mitigation techniques not being adopted into the kernel. And as a side effect every year there are countless vulnerabilities that come out - for which proactive mitigations with up-to-date PoC's have existed for years.

Greg KH basically said in that thread that it would need to be broken up into tons of small patches. Then each patch will have to be submitted and go through the massive politics of getting it upstreamed. This would require a full-time paid team of people doing it, since Linux foundation or similar organizations don't seem to think it's worth paying for a team of security experts themselves to do similar work hardening the kernel.

Additionally, a long time ago (before grsec I believe) the person (or team) behind PaX, whose code is now a significant percentage of GRSecurity, is anonymous and the Linux core refused to accept patches from anonymous developers.

Also for a more meta-discussion on how security is handled by the core devs see Spenders summary here in "KASLR: An Exercise in Cargo Cult Security" [https://forums.grsecurity.net/viewtopic.php?f=7&t=3367](https://forums.grsecurity.net/viewtopic.php?f=7&t=3367)

[1] Spender links to old threads here where people tried breaking it up and submitting small patches:

[https://twitter.com/grsecurity/status/541797486479028225](https://twitter.com/grsecurity/status/541797486479028225)

[https://twitter.com/grsecurity/status/541797673419145217](https://twitter.com/grsecurity/status/541797673419145217)

[https://twitter.com/grsecurity/status/541797780482977792](https://twitter.com/grsecurity/status/541797780482977792)

<comment><USER4> Does systemd even work w/patched grsec kernel? Last I heard Spender was considering writing a security module to get deep hooks into the kernel to handle systemd, so I assumed systemd killed off any hope of more grsec/pax patches making it upstream.

<comment><USER5> I've tried running the grsec kernel on Arch a few times, and I've never gotten it to boot once, it usually just panics immediately. In the same way openSSL was a base of nobody wanting to invest in covering your own ass, there is no interest in having a legitimately secure kernel the way grsec proposes, and even in Arch there are only a few people working on it and while it is in the official repos it really should be in the stock kernel if they wanted to send a message.

</comment></comment></comment></comment></comment><comment><USER6> Status for at least one of the CVEs in Debian is here: [https://security- tracker.debian.org/tracker/CVE-2014-8133](https://security- tracker.debian.org/tracker/CVE-2014-8133) (currently unfixed)

</comment><comment><USER7> How can this/these be exploited?

<comment><USER8> I'm sure this question is important to ask to learn how to protect yourself, but it struck me as a question that is difficult to ask. By asking it, you sound like someone who wants to exploit others vulnerabilities rather than someone who is trying to protect themselves.

</comment></comment><comment><USER9> Is there any information whether the fix is in 3.18.1, which was released yesterday?

<comment><USER10> CVE-2014-9090 and CVE-2014-9322 were fixed in 3.18, just before it was released.</comment></comment>


Ask HN: Is personal bankruptcy a problem for founders? - <AUTHOR>

I'm considering filing for bankruptcy.  I plan to start companies in the future.  This would of course need to be disclosed to investors in any future startups of mine.  Do investors care much about previous bankruptcies?  Or at all? <comment><USER2> probably depends on your position.

I'd think twice before investing in a business person who declared bankruptcy. I mean, it would matter why, and it wouldn't be an immediate no any more than having a failed business would be an immediate no, but it's a black mark. The technical partner having that black mark? especially if the technical partner had a business partner who was responsible (and who would presumably be responsible for the money) well, that wouldn't bother me so much.

<comment><AUTHOR> Thanks. I have played both the CEO role and the CTO role. In the future I would likely be playing the CEO role.

<comment><USER2> ah. Well, then I guess it would depend on if I thought you went through bankruptcy because you started a company without a corporation and it crashed, or if I thought you went through bankruptcy for personal reasons. The latter, in my mind, would pretty much disqualify you, as it suggests you are not good with money.

The former is just fine, assuming you can get me to believe you. (but convincing me of this would be difficult. Everyone with a shopping problem would like to think they were really 'investing' Financial records from the failed company would help a lot, and would provide evidence you are good with money.)

Of course, I invest in my own companies, not in other people's companies, so my opinion may not be representative.

Oh, also, especially if you are young, it will matter a lot less as you get older. We all can relate to doing irresponsible things when we were young.

<comment><AUTHOR> The bankruptcy would largely be a result of funding a web startup years ago with credit cards after having used up savings. The expenses were food and rent and the like.

</comment></comment></comment></comment><comment><USER3> build a company that makes you money and doesn't require investment. what is the problem?

<comment><AUTHOR> The question is, if I want or need investors, might this be a problem?</comment></comment>


The Best Tech Writing of 2010 - <AUTHOR> http://www.switched.com/2010/12/30/best-technology-writing-of-2010/

<comment><USER2> Good list. I thought all of the usual tech blogs have been very weak and most good tech writing is coming from traditional sources or individual bloggers.

<comment><USER3> Tech Bloggers seem to focus more on hype than content. Also, traditional writers do a lot of reasearch before publishing anything. The fact that they have more resources at their disposal helps them.And, Bloggers have limited time from start to the publish point.

<comment><USER2> Yes, they are all in a race to the bottom, mimicking each other.

I wish one of the blogs would hire a good roster of tech writers and put out 2-3 good articles a day, instead of 10-15 gossipy and poorly written articles a day.

</comment></comment></comment><comment><USER4> This subjective and one-sided puff piece with no tech in it - www.marco.org/769340032 - this qualifies as "Best Tech Writing of 2010"?

</comment><comment><USER5> Read only the Zadie Smith one, thought it was a crock.

</comment><comment><USER6> all those nytimes articles require user acct

<comment><USER7> ...or require occasional trashing of nytimes.com cookies.

</comment></comment><comment><USER8> Dang, based on title I expected it to be Paul Graham's Top 15 articles, not that Graham was included in the Top 15.

<comment><USER9> You might find this helpful: [http://www.solipsys.co.uk/new/PaulGrahamEssaysRanking.html?H...](http://www.solipsys.co.uk/new/PaulGrahamEssaysRanking.html?HN)</comment></comment>


Ouya console review: "Pass on it" - <AUTHOR> http://gdgt.com/ouya/console/ <comment><USER2> I actually think that as an inexpensive XBMC TV device + emulator gaming Ouya is an outstanding offering for its price. But if someone expected current gen console compatition here - it means that the product was misunderstood.

<comment><USER3> Yes, I've been thinking about getting one specifically for that purpose: a cheap way to play NES/SNES/GBA/etc. games on my TV (I'd imagine that a Ouya filled with such games would be a great present to a niece/nephew whose family can't afford to pay for modern consoles + games). The Ouya also has Towerfall, which is apparently a fantastic game.

Comparing it to PS3/Xbox/Wii U is missing the point.

<comment><USER4> NES/SNES/GBA? Since you mentioned costs of original games, where will you get legal ROMs for those consoles?

<comment><USER5> _where will you get legal ROMs for those consoles?_

You don't. You put on your eyepatch, grab your cutlass, and raise the Jolly Roger.

<comment><USER6> You've both missed his point, which is: why pirate SNES games but not Xbox 360 games?

<comment><USER7> Whose point?

People don't pirate 360 games because it's probably fairly annoying - you need a 360 console to begin with, then mod it which might need an older one running an out-of-date OS, and likely can't play multiplayer without the risk of your account being banned. Plus the size of games means torrents which means letters to your ISP. And if it's a couple years old you can probably buy the game for $10-20.

Pirating games for older consoles is trivial in comparison - _any_ computer you have and most smartphones can emulate a PS1 or older almost perfectly. And the game sizes are tiny.

If you were asking about a moral justification, there's always the "it's not being sold new, so the makers won't get my money if I buy it used anyway." Though by now at least 95% of games that people actually play have been re- released, so that justification doesn't hold much water.

<comment><USER8> The "makers" of the games (i.e. developers) don't get the money for re- released games, just the publishers do. It does not cost them anything, it's full profit and they own all rights to their distribution. I don't think it makes it more reasonable to support them for making fresh, full money out of completely outdated games.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This review states the Ouya is "hacker friendly" and I think thats far from the truth. It comes with a locked bootloader and, as far as I've been able to research, no one has been able to put any other version of Linux on it.

I think piracy concerns ended up causing Ouya to close their system some, making it less hacker friendly.

<comment><USER10> Does it allow side-loading of unsigned apk's? That wold make it very friendly for some types of hackers.

<comment><USER11> I believe it does. I vaguely remember seeing something along those lines in the setup screens.

</comment></comment></comment><comment><USER12> It does seem like they're interested actively enhancing their library: [http://www.ouya.tv/freethegamesfund/](http://www.ouya.tv/freethegamesfund/)

</comment><comment><USER13> Can't help but feel Ouya's sitting in a niche that someone's going to snap up in 6 months or so like the iPad did to the ill-fated crunchPad/JooJoo. Be it the steam box or someone else.

Perfectly good market, fantastic vision, just not quite polished enough and with not enough money behind it to get over the technical hurdles & polish to win over the consumers (obviously excluding the drama with the crunchpad at the end, which didn't help).

<comment><USER14> I feel that the problem is the price, none of the major console manufacturers have tried (or at least succeeded) in building a console for that sort of money. There's probably a reason for that.

<comment><USER15> The reason the major players haven't made a cheap console is because they (Nintendo excepted) are pushing the boundaries of what "cheap enough" hardware can do. That's necessary for the type of games they want to sell -- but it's not necessary for all games.

I fully expect an Ouya/Google/Apple/GameBerryPi/etc to really find a fun loving, large market at a $100 price tag.

<comment><USER14> Problem is that you are trying to hit a middle ground between people who are gaming enthusiasts and want to play games on a dedicated device be it a console or PC with a fancy GPU. And a larger casual market; many of whom are probably looking to buy games for a system they already own like a laptop or tablet.

<comment><USER15> I'm not sure if it's more accurately described as a middle ground or as a niche: Casual gamers who want to play cheap games on their TV, with a controller, and/or with friends. (Another possible interpretation of "midcore.")

I think Towerfall's popularity is due in some measure to hitting that specific formula: cheap & fun same screen multiplayer; "mobile philosophy" on a television.

I do think overall you're right that the casual market wants to play on devices they already own. It would not surprise me if Apple released a WiFi controller & added a dedicated Games store on the AppleTV (using touch screens while looking at a TV just feels awkward).

<comment><USER14> The problem with having a niche market of people who buy your system because it is cheap is that it's not a particularly profitable thing for developers to target compared to a more serious console where you can charge $50 for a game or a smartphone/tablet where you make your money by selling many copies. So all of the best games end up being ported to other platforms anyway, which reduces the incentive to buy an Ouya unless you have the might to lock developers into exclusive deals.

</comment></comment></comment></comment></comment></comment><comment><USER16> There are two games that we love: Amazing Frog and Bombsquad. The rest don't get played much. Hopefully this situation improves.

<comment><USER17> A few that I've really enjoyed so far, if you don't mind the suggestions:

* Antichromatic (hit and subsequently blasted out of the sandbox earlier this week, effectively Ikaruga mechanic applied to a platformer)

* Inferno & Ballistic SE (same author, same general gameplay, different world mechanics)

* Saturday Morning RPG

I'd love to see an actual vs fighter, but currently lack the free time to even care about hacking one up :/

</comment></comment><comment><USER18> "the idea of an Android console sounds great"

Does it though? Really?

</comment><comment><USER19> Make a game editor, with a decent 2d editor and a nice integrated IDE.

<comment><USER20> That will surely remedy the lack of quality games.

<comment><USER19> Woaaaah, easy there sarcasmo!

That sorta sounds like Sony. Hey lets make our platform an entirely new platform, different from x86 and as hard as possible to get quality game developers.

Sounds familiar?

<comment><USER20> That's quite a stretch. I don't really know what you mean with the Sony comment so I'm going to guess you meant Playstation 3 which was widely considered hard to develop for. When PS3 was released there had been exactly one x86-based mainstream console on the market. Even Microsoft chose to abandon x86 for Xbox 360. PS3 was hard to develop for, but not because it wasn't based on an x86 architecture.

Anyway, to get back on topic: Ouya has a well-know architecture. It has a well-known operating system with good tool support. What sets it apart from an Android tablet is the controller and the fact that you plug it into a TV. When Ouya fails, it's not going to be because it lacked good tools.</comment></comment></comment></comment>


TypeScript – The Myth of the Superset - <AUTHOR> http://blog.jonasbandi.net/2016/10/myth-of-superset.html <comment><USER2> At work I needed a fast scripting environment for Android. Not everyone who'd be scripting for the application knew Lua (or Squirrel) so I went with J2V8 (Java bindings for V8).

The first problem I ran into was documenting the API defined on the Java side of things. I tried Jsdoc, but it was cumbersome for what I was trying to do (expose type information).

I tried Typescript on a whim and fell in love with it. The people who only know Js could still use Js, but the Ts scripts so easy to reason about I disabled Js support in my build system (which uses Browserify and some in- house signing tools to compile the script files into one package I can easily load into V8).

The people who were used to Js couldn't just write everything they would Js as this article describes, but what they couldn't write seemed to be stuff that would break a lot of compile time checks. It was a little battle to get one guy to stop using <any> everywhere, but 9/10 times that he came to me with a broken script, it was something that satisfying the compiler without <any> would have found the issue.

And the Java side now looks so much cleaner because we have a compiler that can check that we're sending it the right types, so there isn't as much work trying to cast everything from Object to different representations it could have in Js. I define interfaces that the Java side implements with 'declare' and get that type checking and autocomplete for exploring the API for free, which is another huge win.

I've noticed a lot of JVM-Js integration (Kotlin has Js interop iirc) and I think Typescript is really great there. Flow looked interesting, but it felt like its approach is more targeted towards existing code bases trying to migrate to it, and we didn't have that constraint

</comment><comment><USER3> I think this is a less relevant issue now that tsc can include plain .js files in builds. I think the spirit of being very close to JavaScript and being easily convertible from one to the other is more important than being a strict superset.

</comment><comment><USER4> Polymorphism of JavaScript functions is a bit of a pain point in TypeScript, I think.

I often got some query methods, that deliver different types of objects, which share a parent class. Like GameObject, Player, Enemy.

        const player = getGameObject('playerId')

Now player will be typed like the return type of getGameObject. If I now try to set an attribute, specific to `Player`, it will fail:

        player.mousePosition = [1, 2]
        // won't work, because GameObject doesn't have a mousePosition

Also, setting the type of player to Player, will fail too:

       const player : Player = getGameObject('playerId')
       // getGameObject could return an Enemy

So I have to tell TypeScript, that I know better

       const player = getGameObject('playerId') as Player
       // Forces TypeScript to treat the return value as Player

<comment><USER2> Why is that last line a problem at all?

<comment><USER4> It implies that TS doesn't fully understand JS.

<comment><USER2> I wouldn't say that, that line is pretty much the main value proposition of the language though, is it really "not understanding JS" as much as extending it?

If you really want it to understand Js you could just cast to Any, but to me it's huge that you can do what you do in that last line. Instead of guessing that Player has a mousePosition property, after casting you get told it has one, and get it's exact type.

<comment><USER4> To me it seemed the other way around. By casting, I'm telling the compiler that it has a mousePosition property.

But I think you're right. This is an simple example and the Player object could have a huge bunch of properties I don't need to guess later, I just need to cast and be done with it.

</comment></comment></comment></comment></comment><comment><USER5> tl;dr The TypeScript compiler is strict, so it won't let you compile JavaScript that contains what it assumes are mistakes. I love that about TS, and it's one of the main reasons to use it.

The package incompatibility is different, but I've never had trouble using any JS or TS package in TS, so it doesn't seem to be a practical issue.</comment>


InternStore: There is an intern for that - <AUTHOR> http://internstore.com

<comment><USER2> There's something wrong if I can't tell what the site does from visiting it.</comment>


Use Your own Encryption Keys with S3's Server-Side Encryption - <AUTHOR> http://aws.amazon.com/blogs/aws/s3-encryption-with-your-keys/

<comment><USER2> Server-side encryption.

Sigh. Trying to think of a really pithy analogy... something like taking a taxi to a bank heist.</comment>


RustBelt: Logical Foundations for the Future of Safe Systems Programming - <AUTHOR> http://plv.mpi-sws.org/rustbelt/#project <comment><USER2> How do you address the inherent unsafeness of hardware? Even "pure" functional languages are hacking around this...

<comment><USER3> What do you mean? Do you mean that hardware is unreliable or might break and thus even a sound program, or a program that doesn't do anything that counts as unspecified behaviour, is not 100% safe? Or that with "unsafe" escape hatches often needed to directly interop with hardware are a problem?

<comment><USER3> If it's the former, I agree.

If it's the latter, well, in Rust, the norm is to design safe abstractions around unsafe code. For example the vector class of the Rust standard library contains some unsafe code, but with the all parts that are unsafe being private, the public API exposed is essentially safe.

If this project comes up with reasonable semantics what can be considered to be "safe" with unsafe code, we can verify, that the unsafe bits of the standard library (and other libraries) are being used in a safe manner.

</comment></comment></comment><comment><USER4> They're hiring "postdocs". Do "postdoc" positions in Germany mean, as in the US, paying $30K for people who could make $200K in industry?

<comment><USER5> CS postdocs in the US are certainly not paid $30k.

Source: I've been a postdoc in CS, and I currently employ postdocs.

<comment><USER4> OK, $44K. [1]

[1] [http://www.payscale.com/research/US/Job=Postdoctoral_Researc...](http://www.payscale.com/research/US/Job=Postdoctoral_Research_Associate/Salary)

</comment></comment></comment><comment> irq-1 Rust 1.5 src has 2121 instances of "unsafe {". Didn't expect it to be so high.

<comment><USER6> That's not a particularly useful metric, because that would also be counting all the occurences in documentation (Rust makes extensive use of executable docstrings, so restricting your search to just .rs files doesn't solve the problem), test cases (where you absolutely _want_ lots of tests for unsafe functionality, and Rust often puts tests in the same file as the functions being tested, so excluding certain directories doesn't solve the problem), all the APIs that wrap C interfaces (where unsafe blocks are necessarily unavoidable), and bits of the compiler itself (for e.g. talking to LLVM).

Even then, the standard libraries are exactly where you _want_ your unsafe code to be; safely encapsulating useful unsafe patterns in a highly-visible and well-audited venue is ideal, and reduces the usage of unsafe code in (presumably less well-audited) third-party libraries.

<comment><USER7> Here's a concrete data point in rust 1.5.0 to critique:

      $ grep 'unsafe {' src/lib* -r |wc -l
      1529

I'm skipping src/test and src/doc and a few other things, so this is likely a mild under-estimate on that front.

Docstrings seem to always require a comment leader, so let's ignore any lines where the first non-whitespace characters are not '//'.

      $ grep 'unsafe {' src/lib* -rh |grep -v "^\s*//" |wc -l
      1480

Inline tests are created using 'mod test', so let's look:

      $ grep 'mod test {' src/lib* -rl |wc -l
      6
      $ grep 'unsafe {' `grep 'mod test {' src/lib* -rl` |wc -l
      13

So of 1.5k occurrences, 13 lie in modules with inline tests. Let's conservatively ignore them all.

Final count of non-docstring non-test occurrences of 'unsafe {' in the 1.5.0 sources: 1463.

<comment><USER8> Minor point, (= 1461 (- 1480 6 13)), not 1463, unless I misinterpreted.

<comment><USER7> Sorry I meant to say (- 1480 13) = 1467.</comment></comment></comment></comment></comment>


Include what you use, remove superfluous #includes - <AUTHOR> http://code.google.com/p/include-what-you-use/

<comment><USER2> I implemented this for Clojure a couple weeks ago and wrote about how it works: <http://technomancy.us/148></comment>


The Truth Behind Last.fm Story: Techcrunch conned? - <AUTHOR> http://www.guardian.co.uk/technology/2009/may/28/not-safe-for-work-last-fm <comment><USER2> I dont like the implication that techcrunch and last.fm are both equally innocent victims in this.

techcrunch's traffic no doubt rose well above average during the whole affair, they have a few detractors questioning their legitimacy, but where are they? techcrunch deleted every comment that wasnt calling for the death of last.fm from each post.

whereas last.fm, they may have had some extra traffic, but they have had quite a few people deleting accounts, 3 posts on the worlds largest(?) tech blog along with threads on slashdot and a long list of people in their own forum worrying about being sued for using last.fm.

combine that with the ridiculous practice of posting these attacks on friday nights and the fact that techcrunch were the only people to hear from this tipster, its hard to pass off techcrunch as the innocent victim.

<comment><USER3> When you have a scoop, you publish it. You don't think: "oh well, it's getting late on Friday, let's wait until Monday when every other news media outlet has a chance to cover this as well".

So the "Friday allegation", to me, is completely misguided.

The denials have been pretty suspicious actually, at least the way TechCrunch and the Guardian report them. Over the years, I got used to reading between the lines.

When a famous athlete says "the allegations about my doping in magazine XYZ are completely false", it's not a denial. It's a carefully crafted statement to avoid any legal problems. If the athlete says "I never took drug XYZ", then that's a much stronger statement.

In geek terms, the first statement is a "nop". The second one is either true or false (0 or 1).

<comment><USER4> If you want to be considered legit, when you have a scoop, you investigate before considering publication.

<comment><USER5> TC seems to post a fair number of stories that are "too good to check"

</comment></comment></comment></comment><comment><USER6> 2 big points im not sure he addressed.

\- TC originally _explicitly_ accused Last of handing over the data. Which everyone agrees now didnt happen. So probably Last's original "TC are full of shit" response could be considered partially fair?

\- This "source" has just disappeared? That's interesting... not wanting to sound like I am accusing TC but it's more than a tad suspicious. Has someome been leading them along? Sounds a bit like it to me!

Otherwise good article :D

</comment><comment><USER7> Wake me when it's all over. It's just too much.

</comment><comment><USER8> The truth is that "there's no story". Because somebody (everybody?) is stonewalling.

Paul Carr provides a good summary of what (impaired) journalistic-like investigation has been done so far.

I don't follow Carr, but glanced around the guardian.co.uk page and noticed that the 3rd "most followed stories" was, "Woman may have kept mother's body in freezer for 20 years." Ah. Well, I guess Guardian is not exactly targeting HN readers.

<comment><USER9> The Guardian is one of the UK's biggest newspapers, and is generally known for being tech savvy. This is a decent "elevator pitch" summing up of the story for the Guardian's typical audience.

<comment><USER10> The Guardian is a good source and certainly understand tech the best of UK newspapers (they have an api, post the raw data used in articles, host barcamps/hackdays, etc).

Carr on the other hand is know for bitter opinion pieces, such as this one about the Le Web conference [http://www.guardian.co.uk/technology/2008/dec/10/startups- in...](http://www.guardian.co.uk/technology/2008/dec/10/startups-internet)

<comment><USER11> That piece Carr wrote about Le Web was a hack job -- yet another manifestation of the undying British national habit of badmouthing the French on every possible occasion.

Done by professional comedians once in a while it's fun. Done by an entire nation it's disgusting.

Compared to Carr's, Michael Arrington's article on Le Web seemed like a balanced critique, and that's saying something.

<comment><USER12> > Done by an entire nation it's disgusting.

One piece of journalism does not equal the opinion of an entire nation.

</comment></comment></comment></comment></comment><comment><USER13> What baffles me is how incredibly incompetent the PR operation of CBS is. This is after all one of the biggest media companies in the world.

Instead of issuing an unequivocal joint CBS+Last denial, they keep stressing how unimportant a source blogs are. This isn't just a matter of truth but also one of professionalism. It's yet more evidence that media companies have been living under a stone for many years and any startup should avoid ending up in the claws of one of those.

</comment><comment><USER14> Great post. I won't hold my breath to see it linked on techcrunch

<comment><USER15> Great post? He basically said, "He said, she said, he said again, she said again and we don't don't know what happened." Which is what everyone already knew.

<comment><USER16> Exactly : weak article !

Instead of giving a factual opinion, he's biaised because, well, Last.fm are his friends and TC are his friends too.

It seems like he doesn't want to be in conflict with any of them.</comment></comment></comment>


Mozilla temporarily shuts down Firefox Send in response to malware sharing - <AUTHOR> https://www.techspot.com/news/85979-mozilla-temporarily-shuts-down-firefox-send-response-malware.html <comment><AUTHOR> [https://send.firefox.com](https://send.firefox.com) currently not accepting submissons.

"Firefox Send is temporarily unavailable while we work on product improvements.

We appreciate your patience while we make the Firefox Send experience better."

For what it's worth we've seen a couple of malware links come through this way in the past month.</comment>


The Open Plan Office and the Extrovert Ideal - <AUTHOR> http://www.mattblodgett.com/2015/02/the-open-plan-office-and-extrovert-ideal.html <comment><USER2> Every time this debate pops up on HN, I find this quote from Bell Labs scientist Richard Hamming interesting to consider:

 _I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don 't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, 'The closed door is symbolic of a closed mind.' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame._

Source: [http://www.cs.virginia.edu/~robins/YouAndYourResearch.html](http://www.cs.virginia.edu/~robins/YouAndYourResearch.html)

<comment><USER3> This is quite obviously a metaphor. He's talking about lone wolves without the habit of seeking collaboration. From the same source further down, regarding brainstorming:

 _There were a group of other people I used to talk with. For example there was Ed Gilbert; I used to go down to his office regularly and ask him questions and listen and come back stimulated. [...] Yes, I find it necessary to talk to people. I think people with closed doors fail to do this so they fail to get their ideas sharpened, such as ``Did you ever notice something over here? '' I never knew anything about it - I can go over and look. Somebody points the way. On my visit here, I have already found several books that I must read when I get home. I talk to people and ask questions when I think they can answer me and give me clues that I do not know about. I go out and look!_

And he's speaking from a time before ubiquitous email and online chat.

Do you really imagine that the solitude-seekers' problem is that they want to avoid collaboration? Do you imagine that forcing them into the mind-blender type of office eight hours every day of the week is necessary because we need to make them collaborate more, to make sure they know the right things to work on?

</comment></comment><comment><USER4> As someone with the authority to make the necessary changes to our office environment, it frustrates me to read these kind of blog posts. I have read a couple dozen similar posts which merely complain about open offices, but offer absolutely nothing in the way of practical solutions.

We don't have the opportunity or space to give everyone their own dedicated office, and cubicles I'm sure would be a living hell. I've looking into draping fabric from the ceiling, but you'd be surprised how challenging the logistics of setting something like that is (there are very few products in the market to support fabric like this, and we can't drape them from the drop ceiling due to weight). I've looked into free standing walls, but they tend not to have the sound absorption that is typically desired.

I'd like, for once, to read an article about practical solutions to this problem rather than just another person complaining about open office spaces thinking they've stumbled upon some undiscovered idea.

<comment><USER5> The practical solution is to _spend more money_.

That means high-wall cubicles (6'-8') or private offices. Those have been the known solutions for forty years. I doubt other solutions exist.

Yes, this will cost more. No, there isn't a shortcut.

<comment><USER6> _The practical solution is to spend more money._

This is immensely frustrating because it is clear the OP doesn't have the money. So how do you do this if you don't have money for anything but Lucite tables and chairs?

<comment><USER7> You don't. You set up your open plan office, and you take what employees are left over after the ones who are skilled enough to have their choice of working environment. This is still quite a lot of very skilled employees. Leverage them as best you can to make enough money to give them offices.

<comment><USER6> Our solution is to keep everyone remote till we can build good spaces, however that is not possible for everyone. It seems ridiculous that people think there are only binary options here.

</comment></comment></comment></comment></comment><comment><USER5> We don't need pages of workplace psychology to explain the open plan office.

Open plan just has lower visible costs. Twice as many workers per square foot is very compelling math.

The cost of lost productivity is hidden. The reduced cost of your office lease is very visible.

<comment><USER8> We had a presentation on the new "Studio" buildings at Microsoft. A snappy team from the folks responsible for designing them told us about color schemes and that each building had a theme, in stone and wood and so forth. They waxed eloquent about carpet and the cafeteria and I was thinking, _what are they hiding?_

Then they got to the places where we were going to work. "We call these six- packs." Pods of six people crammed into a small area with low partitions, very little space for personal items, and little regard to our actual work (e.g., whiteboard space, or room for equipment, or even sufficient power).

They tried to retract the word six-pack. "Oops, we weren't supposed to say that. We're supposed to call them 'Villas'".

Villas.

I called them "moo towns".

If you were lucky you were in a six-pack with people working on the same thing as you, and then the conversations around you probably had something to do with work. If you were randomly assigned a six-pack the chances were that you were being continually interrupted by stuff that you didn't care about.

And _of course_ we ran out of space, and even the walls in the six-packs were removed, and all the book-cases, and now there were eight people in a space designed as a tight fit for six, and places in the building started to _smell_ bad (I wish this was hyperbole). Let's not even talk about security, as in having to lock stuff up at night . . . um, where, exactly?

Open plans are horrible.

<comment><AUTHOR> This is the kind of shit that makes me angry. Microsoft should know better. Slick presentations about bullpens being the future of work, like it's self- evident. A generation of software engineers are going to come up with the belief that these sorts of working environments are standard, and then wondering why they're so stressed out and tense all the time.

</comment></comment></comment><comment><USER9> Anecdote: Working IT in an open cubicle environment is absolute pure fucking _hell_. Nevermind that the last guy left me with cable management that would make a three year old sick to their stomachs, not having an area that I can cordon off and close when I absolutely _MUST_ shut out the world and focus on a task has been a mental and motivational drain. (This is compounded by being 1 IT staff in a company approaching 120, but that's a different affair)

I agree with everyone who says "Sure you may be saving leasing costs but you're sacrificing so much more". A perfect example of this is my sales center: an open office plan with desks lined up and about 60 people in a room the size of a large 1br condo, all talking at once, not to mention this obsession with having music played over speakers during business hours and loud annoying gongs going off whenever someone makes a big sale-I may as well be working on a trading floor (first the dashboard TV makes a big gong, people applaud, and then the person who made the big sell goes and bangs a _physical_ gong, more applause. If I were a sales person trying to work through all that I'd quit immediately. I wonder if an exit interview survey of the sales people we've lost in the last month alone would testify to "productivity" related causes for their departures, and in high numbers). Customers can rarely hear agents, agents can rarely hear customers; I looked at my last inventory purchase and we blew $2000 in a month on replacement headsets because people kept slamming theirs down in frustration, ultimately damaging them because of the inability to hear sales calls. If my Android sound meter app is accurate at all, fully staffed the sales wing reaches 92dB in ambient/background sound.

And a litany of other problems that would be solved could I get senior management to take conditions as seriously as I do, and express a willingness to invest in the worker beyond a "Here's your paycheck, get back to work".

Open _spaces_ are good. A commons area lightly equipped, maybe with a phone and a tv for quick 'huddles', I'm all about. 100% open office however I can't wait to go away forever. Thankfully we're moving offices soon. Regrettably, it's just a larger "open" design.

<comment><USER10> If your measurement is correct, then your office environment violates OSHA regulations.

[https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_tab...](https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=standards&p_id=9735)

<comment><USER9> That's quite valuable information to me; given I'm sick of troubleshooting that damn wireless music box and have been trying to get rid of it for months.

This is ammunition much needed.

</comment></comment></comment><comment><USER11> Stop making this an introvert / extrovert thing. I don't care who you are. You can't concentrate when someone's talking on the phone.

[http://healthland.time.com/2013/03/14/why-overheard-cell- pho...](http://healthland.time.com/2013/03/14/why-overheard-cell-phone- conversations-are-so-annoying/)

</comment><comment><USER12> Someone at Dropbox made a great suggestion to me the other day. What about having something like the Quiet Car? ([http://www.amtrak.com/onboard-the- train-quiet-car](http://www.amtrak.com/onboard-the-train-quiet-car))

Basically, you'd have a part of the office where you could take your laptop and go work in complete quiet. No conversations louder than a whisper, no music playing, no bringing food back to your desk. If you need to do any of those things, you go elsewhere.

<comment><USER13> I've seen this before. Capital Factory in Austin had a quiet room just like you describe. It was full of people when I was there.

</comment></comment><comment><USER14> A basically excellent post. With one minor nitpick:

"A building filled with individual privates offices and no common areas would go all the way to the introvert end."

I've been there, and the reality is people in extroverted moods crowd into one office, or schedule endless meetings in a conference room, or just hang out together.

Also, its mood in addition to personality. I'm probably 90% introverted and 10% extroverted in feeling. I don't mind a quality meatspace discussion, just keep it to a reasonable fraction of my day, not all the time or when I'm trying to concentrate or when I'm trying to do actual productive work.

I'm a bit miffed at the author for missing the obvious on-call analogy that if open plan offices are so great, then every time I get an "emergency" call at home or jump on a conference call when I'm out of the office, then I should run to the nearest playground or daycare and sit in the center of the loudest most disruptive room. After all, that noise is supposed to make me productive. I can only imagine in horror one the result of those architects redesigning the study areas or labs back at uni.

When I'm doing my own work at home in an environment designed for me to be ideal, when I'm concentrating as hard as possible, it probably shocks some open office stockholm syndrome victims that my near perfect home conditions don't involve 25-50 televisions blasting reality TV at full volume, simultaneously, while I work.

And there's also the denigration factor, not mentioned in the article. You mere proles don't really think, so you don't need conditions to think. Us managers are paid to do all the thinking so we have offices. You proles belong in your sweatshop, you losers. Its a very intense, negative message. Architecture has meaning, and designing a daily kick in the nuts into your office is just inhumane. I'm sure its very funny for our superiors to watch us suffer a la Mr Burns style (oh how cute, they think we care about how badly we're treating them, ha ha as he strokes his villain cat). Mixed offices of management in offices and proles in the inhumane open area results in feelings similar to having "regular" and "colored" water fountains back in the old days. "We know is sucks, but it keeps you lower animals in place."

Its not just that open office advocates are wrong, its that they're so wrong that a thoughtful discussion will inevitably appear to be parody.

<comment><USER15> "I'm probably 90% introverted and 10% extroverted in feeling."

IOW, you're a fairly normal introvert, then. Most introverts like people, enjoy conversations and parties, et cetera. But such activities take energy, so after a while you need some time alone to recharge. (If you're lucky, your SO is similar, so time spent with them also lets you recharge).

Extroverts are similar -- they can enjoy time spent alone, but it saps their energy, so after a while they have to go talk to somebody to recharge. That's why they're so annoying in a software development shop -- their job is "alone" with a computer, so every once in a while they need to interrupt somebody to play ping pong or have a conversation, et cetera.

</comment></comment><comment> mark-r The counterpoint he tries to consider at the end of the article is missing the point. No matter how those successful companies operate today, how did they operate when they first became successful? If it _was_ an open plan, how many people were in the room, and how many different things were they doing?

</comment><comment><USER16> "If getting a desired product of work requires collaboration, then people will collaborate."

This is one of the main points of contention between the various parties, and defining whether or not something _needs_ collaboration is often ignored.

The entire project might need degrees of input from multiple parties, but often what's needed is for one person to actually _get something done_ , the invite collaboration/feedback/input. Forcing people to work together at every single step to get "collaboration" is simply wrong, but it's one of the justifications for "everyone in the same room."

</comment><comment><USER17> There are a few comments here and directly at the article which mention the concept of a balanced work area, with open spaces as well as private spaces. So far, nobody has given an example of this.

I happen to work in a balanced office. Our desks are all located in a former warehouse. We're all mostly developers in my area here. There's a culture of ambient noise and conversations, frequent interruptions for collaboration, etc ... all WITHIN the warehouse area.

HOWEVER, we also have dozens of small phone booth (one person) rooms where people can go to take calls or work independently PLUS dozens of 4-6 person collaboration rooms PLUS adequate meeting rooms for larger groups PLUS a couple quiet rooms where anything louder than typing is heavily frowned upon PLUS a reasonable work-from-home policy when employees require it.

Yes, this is Enterprise (so not that exciting, but they can afford to provide such a location). Yes, there are tradeoffs (you are still expected to be in the office a reasonable amount of time, dependent on your individual manager and management chain; sometimes the warehouse noise is pretty distracting; etc). Given all that COULD go wrong here, I have been pleasantly surprised by how RIGHT this company has gotten it. A good chunk of this has been the work culture allowing employees to adapt the available space to what is needed for each individual team.

I'm sorry so many of you have experienced the horrible implementations of open office. I've been there previously. I only hope that more companies see wisdom in mixed and balanced work environments in the future.

</comment><comment><USER18> This is a GREAT article, not so much for the extrovert angle (I don't know, I'm extroverted _sometimes_ \-- I just can't concentrate over people yelling), but because of the headphone parts at the bottom. So many times does "just use headphones" get thrown at people who protest the open office reduction, but they don't realize that wearing headphones all day is uncomfortable (and probably dangerous), even if we love music - and it's also distracting.

When we have things like IRC/Hipchat/Slack, email, and video chat, having a door is no more a problem, because we can get a hold of anyone asynchronously.

Therefore, if anything, it should be EASIER to have doors now.

Sadly, the best office environment I've seen was at AT&T in 2000-ish. Employees had HUGE cubes, with quite a lot of office space for managers. Cube size reduced significantly over the last decade and a half until now cubes are viewed as somehow decadent. We laughed at cubes relative to offices then, we would LOVE to have them back now.

I'm looking for the work-from-home revolution to take over or companies to at least realize what they are doing with the open plan stuff for development. Technology makes doors not exist - so we should at least be able to have quiet.

</comment><comment><USER19> You know what I really liked about my time at University? There was a wealth of options to suit your study style. Imagine your University only had open floor plan libraries, where the only place they gave you to study was a loud, visually distracting environment. Or, you could go the other way where the only place to go to study was the quiet floor of the library. Universities are great places to study because they cater to many different personal styles of study. Your goal is to learn and they provide different styles of learning environments in which to study. It baffles my mind that employers, most of whom, one would assume, went to University, then create a single style of work environment, and think their jobs done. Providing many different styles of office spaces for the many different types of people in your employ would seem to be a prudent decision. Allow your employees to find the style that works best for them instead of forcing a one size fits all solution.

</comment><comment><USER20> Multiple comments are mentioning wearing headphones with loud music. But what about __earplugs __(the disposable foam type)? I've worn them during physical work (with loud machines) and, at least for me, they were very effective. I felt I had more energy and focus. Has someone tried them for office work?

<comment><USER21> Those aren't really designed for long term daily use, can lead to accumulation of wax and serious infections if used repeatedly and continually.

Also in my case they put too much pressure on the canal which eventually gets quite painful. When I was a mechanic it was more of a hassle but much better for my ears to wear proper ear muffs instead of disposable ear plugs.

</comment></comment><comment><USER22> > _Introversion—along with its cousins sensitivity, seriousness, and > shyness—is now a second-class personality trait, somewhere between a > disappointment and a pathology. Introverts living under the Extrovert Ideal > are like women in a man's world, discounted because of a trait that goes to > the core of who they are. Extroversion is an enormously appealing > personality style, but we've turned it into an oppressive standard to which > most of us feel we must conform._

I say this as a highly introverted person who spends most of his free time alone with this thoughts: Jesus. Are we just looking for ways that the world has been unfair to us? Is that what open offices are now? A way for the uncaring society to oppress us special snowflake introverts? That quote is so insulting to me as an introvert because it takes such a solipsistic and ego- stroking view of the world: that people who are successful are successful because they fit into the world better, not because they are comfortable and adapted to living in a world that isn't perfectly suited to them. I enjoy my quiet and find working in an open office discomforting. But I can't imagine the person who's so fragile that they have to invent ways the extroverts are oppressing them to deal with that discomfort.

> _Is this a true story? I don't know. Is it a bit overly dramatic to compare > an open plan office to a sweatshop? Perhaps. But I think there's a valid > point in there: quality of life matters._

If you want people not to take our profession seriously, keep comparing what we do to working in a sweatshop. Software engineering by and large is one of the cushiest jobs around. Sitting in a chair (or realizing that sitting all day is too dangerous, so choosing to stand (on a padded mat)) in a climate controlled office with access to bathrooms, running water and in a lot of cases, food on demand is about the farthest away you can get from sweatshop. Our quality of life is so good, we're focusing on the last 1% of the problem; the fact that we're complaining that the _layout of the office isn 't ideal for our psyche_ should clue us in to that. Let's keep some perspective here.

<comment><USER23> The word "sweatshop" is improper, you're right about that. But is it really unfair to compare modern software factories to, well, factories?

Most factories today are very clean, and safe. But they're not organized to help foster original thought, which is what software (should be) made of.

</comment></comment><comment><USER24> There's one place where an open-plan office makes sense: a trading floor. This applies even to many species of algorithmic trading. That's because you have cases where a message (such as "our quotefeed is giving us stale data") needs to get out quickly.

The trading day is also, I'll note, only 6.5 hours long. And people who don't get 25% raises (or more) per year leave. It's a stressful job and unless you're making $750k+ after 6-8 years in, it's not worth it to deal with the negatives of being on a trading floor.

Open-plan began to go into vogue as a backdoor mechanism for age discrimination, due to studies showing that older people were quick to associate them (and visibility from behind) with low status and therefore leave. Two decades later, I doubt the intention behind tech companies using these plans (and almost all do) is so negative as that. I don't think there's any negative intent anymore; it's just something that's done because (a) it's cheaper, (b) it's more tolerant of rapid growth, and (c) it's how things have "always" been done.

As long as people _can_ step away without stigma or punishment, I don't think that open-plan offices are inherently evil. The problem is that few offices have enough quiet space to allow for that.

As for "the extrovert ideal", I don't know what to do about that. It seems to be human nature. People with families, non-drinkers, introverts, women except through the immense effort needed to be socially available but not seen as available in other ways... are never going to be "the cool kids". What I've learned, though, is that while "cool kids" get a quick start, they don't hold it and "cool" doesn't last. It's not useful to envy them because, while they may appear to be moving fast at one time, the 5-year picture is not especially desirable.

<comment><AUTHOR> > Open-plan began to go into vogue as a backdoor mechanism for age > discrimination, due to studies showing that older people were quick to > associate them (and visibility from behind) with low status and therefore > leave.

Do you remember where you read this? The bit about visibility from behind being associated with low status is especially interesting.</comment></comment>


Show HN: Hacker Newsanchor – Listen To HN - <AUTHOR> http://hidden-bastion-5609.herokuapp.com/

<comment> aps-sids In FF 29 console, its giving this - "Media resource [http://hidden- bastion-5609.herokuapp.com/2014-05-09T02:11:37...](http://hidden- bastion-5609.herokuapp.com/2014-05-09T02:11:37Z.mp3) could not be decoded."

I downloaded the file myself and listened. Looks cool. (y)

Anyway, what are you using for text text-to-speech conversion?

<comment><AUTHOR> Hm, so far I've only tested it in Chrome, I'll have to look into that.

I'm using the Google Translate TTS Api[1] - had to do some manual parsing + replacements to make some words sound right, but overall it's been stellar, especially compared to most other solutions. It also didn't cost a dime, which is nice.

[1] [https://translate.google.com/translate_tts?tl=en&q=Hacker+Ne...](https://translate.google.com/translate_tts?tl=en&q=Hacker+News+Anchor)</comment></comment>


The Flying Boat - <AUTHOR> http://bomega.com/2008/09/03/the-flying-boat/ A nice metaphor for a common mistake entrepreneurs make when formulating goals and starting a business... <comment><USER2> Excellent. This is a dangerous pitfall that can snatch defeat from the jaws of victory. If you've based your businesses around a boat, and you're convinced there's a market for it, then don't go turning it into a plane at the last minute, or you might end up with neither.

</comment><comment><USER3> If he was a real entrepreneur, he would have made it with the boat... Nice story though!

</comment><comment><USER4> A nice reminder. Shit, where did I put that propellor...

</comment><comment><USER5> Enjoyed that one! Nice metaphor...

</comment><comment><USER6> like the cartoon as well</comment>


Top PR Firms Promise They Won't Edit Clients' Wikipedia Entries on the Sly - <AUTHOR> http://adage.com/article/digital/top-pr-firms-edit-wikipedia-sly/293634/

<comment><USER2> Pinky promise, guys!</comment>


Sleep is Garbage Collection - <AUTHOR> http://blogs.discovermagazine.com/80beats/2009/04/03/sleep-may-prepare-you-for-tomorrow-by-dissolving-todays-neural-connections/ <comment><USER2> If sleep is garbage collection, can I switch back to old malloc/free? So I can do it more evenly over the day? :)

<comment><USER3> Modern garbage collection is done more evenly:

[http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...](http://en.wikipedia.org/wiki/Garbage_collection_\(computer_science\)#Stop- the-world_vs._incremental_vs._concurrent)

Perhaps the brain could do something similar.

<comment><USER4> In software, optimizing this type of garbage collection for low pauses usually results in reduced application throughput. Evolution in general clearly does not favor "low pause" sleep patterns.

However, there are anecdotes of rare people that subsist on "low pause" sleeping. Allegedly, Thomas Edison had a 24 word day and frequently cat- napped. Contrast that with Einstein who allegedly slept 10 hrs a night.

For modern garbage collection systems (e.g. the JVM), there is no single setting that is best (or even acceptable) for all applications. The same is probably true for sleep patterns.

<comment><USER3> _Evolution in general clearly does not favor "low pause" sleep patterns._

Evolution does not consider every possibility. And when it does consider one, it doesn't necessary "implement" it well.

<comment><USER4> Well, if the genes regulating sleep patterns are half as tedious as the gc params for the 1.4.2 JVM, I wouldn't want to consider every possibility either:P

</comment></comment></comment></comment></comment><comment><USER5> In yet another example, the overhead for automatic memory management is shown to be prohibitive.

<comment><USER6> The dominant species on earth (humans) sleep, the generally believed to be smartest animals sleep (humans, monkeys, dogs, various birds), the biggest (elephants, giraffes), the hunters (big cats), the hunted, herbivores, omnivores, the dominant type of fruit fly (in the article) sleeps. Even creatures that would drown if they went unconcious (dolphins, whales) have a kind of sleep.

What, exactly, has it prohibited?

<comment><USER5> Because we're currently the smartest animal, you suggest we couldn't be better if sleep were not required?

<comment><USER6> I do not suggest that. I merely ask you to support your jokey suggestion that the overhead of sleep is prohibitive when it doesn't seem to have prohibited ... anything.

<comment><USER5> If we didn't require sleep (and thus had 8 more hours each day we could work) we could produce far more as a race. It's not like it's some crazy suggestion, it's obviously true and unrealistic at the same time.

<comment><USER7> Beggars in Spain is an interesting treatment of that idea:

[http://www.amazon.com/Beggars-Spain-Trilogy-Nancy- Kress/dp/0...](http://www.amazon.com/Beggars-Spain-Trilogy-Nancy- Kress/dp/0380718774)

</comment></comment></comment></comment></comment></comment><comment><USER8> Subjects taking modafinil can go without sleep for weeks. And studies show no learning decrement in subjects taking modafinil. So is sleep truly required for humans?

Memory in humans and other animals may so different from that of fruit flies that drawing such a general conclusion as "Sleep is Garbage Collection." may not be valid.

</comment><comment><USER9> Sleep = GC and more available synapses = smarter*

So smarter people need less sleep?

Is the converse true?

* [http://www.telegraph.co.uk/scienceandtechnology/science/scie...](http://www.telegraph.co.uk/scienceandtechnology/science/sciencenews/3343912/Study-traces-the-evolution-of-the-human-brain.html)

<comment><USER10> Do you mean that smart people need less sleep to be able to perform a particular task, or that smart people need less sleep to perform at their own peak?

The above analogy leads more naturally to the first conclusion. Give a smart person a cognitive task to perform, and gradually deprive him of sleep; eventually, his performance will be reduced to the level of the average person.

It's less clear how the second conclusion would hold -- that smart people are _incrementally_ affected less by sleep loss than average people. In other words, a priori, I don't think there's much reason to believe that a smart person would be impaired less by losing an hour of sleep than an average person would.

<comment><USER9> I wasn't aiming to go that deep, but to answer your question I meant the ability to perform any given set of tasks.

Deriving the second conclusion needs a lot more data. Assuming there is no analog for swapping to disk, the biggest missing piece is the rate of GC. Is it the same for everyone? Additionally, is a given person's GC rate constant? When I go without sleep for two days, I usually need more sleep than when I missed sleeping for just a day. Does this mean there is more memory to reclaim? Or that my GC rate has been impaired? Or both?

More interestingly, how do 'brain-building' foods and activities affect sleep requirements?

</comment></comment></comment><comment><USER11> I must have a very aggressive GC because my memory is all but worthless for everything besides code.

<comment><USER12> I have this too. I find it disturbing.

</comment></comment><comment><USER13> I always thought so,I think it does some defragging too.

</comment><comment><USER14> Nice one on the title soundsop! Great summary of what the article is saying in terms that are familiar to us here :p</comment>


Early Bird Special $1 for the new invention "Intelishake" delivered to you door - <AUTHOR>

Hi guys, you asked to be informed when it is live, we are now live, get it quick!<p>https://www.kickstarter.com/projects/1593175966/intelishake-smart-sports-drinks-bottle-built-in-st <comment><USER2> Wow, I signed up to Kickstarter to specifically get your email about this, and I'm finding it a day after and never got an email.

</comment><comment><USER3> Looks like the early bird is already gone?

Very nice product though btw

<comment><AUTHOR> thank you! Sorry you missed it, however if you would still like one, your backing would be appreciated!

</comment></comment><comment><USER4> really? putting the link in the text and not even making it clickable(if even possible) when you have so little content that the main link should just go to the kickstarter?</comment>


Show HN: What's in My Picture - Detect human pose,face,text,objects,and nudity - <AUTHOR> https://www.whatsinmypic.com <comment><AUTHOR> Hi all,

What's In My Picture is a way for people to gain insight on what their images contain without seeing them. It allows people to detect human pose key points, face orientation and eye gaze direction, objects, nudity, and text from their images. It also provides a feedback functionality to measure the level of success of each image processed in order to do further improvements to the results.

Would really appreciate some feedback, it's still a work in progress.

Thanks, Edgar</comment>


Show HN: Branch – Mobile links that pass data through install and open - <AUTHOR> http://www.branchmetrics.io/?hn=show

<comment><USER2> If an app is a social app (like in the animated gif demo), that would mean that the app creator already has some server code. Creating a custom link would be pretty easy in that case. I'm not sure if i understand the use case here.

<comment><USER3> The use case here is that a user can go from a link in an SMS, email, facebook post, tweet, etc. to app store for install and once installed goes directly to the content shared. Right now a link could take you to the app store to install but once installed you would not be able to immediately see the content that was shared with you since it's difficult to figure out which user had installed the app and whether that user was the one that got the original link. I am going to keep an eye on this for when I'm ready to launch my app...

Edit: Here's a link to the article that describes the use case in more detail [http://techcrunch.com/2014/09/23/branch-metrics- raises-3-mil...](http://techcrunch.com/2014/09/23/branch-metrics- raises-3-million-from-nea-for-more-intelligent-deep-links-that-make-apps-work- like-the-web/)

</comment></comment><comment><USER4> Not to be confused with Branch, the social discussion platform: [http://branch.com/](http://branch.com/)

</comment><comment><USER5> How are you doing the tracking across the app store? Some kind of cookie in Mobile Safari, or attributing based on time/IP address correlation?

<comment><AUTHOR> Alex with Branch here. Let me try to explain how it works. Basically, we use different technologies in different scenarios with the goal to deliver the user to the app as fast as possible.

First off, the most basic case is where we know the user has the app installed. In this case, we use the standard URI scheme based deep link which opens the app up right away and passes the link data. We also handle the case where they had uninstalled the app, by taking them to the app store.

If we have never seen a user before across our entire network of apps based on our first party cookie, we use a mechanism called fingerprinting. It's commonly used for mobile app install attribution to tell a marketer how many installs were generated from a particular advertisement shown in another app or on a mobile site. Basically, we collect as much information as we can in the browser (time, OS, screen size, IP, etc) before redirecting them to the app store. When the user opens up the app, we generate that same set of information inside the app and send it back to our service to match up with a pending browser fingerprint. In the case of a match, we know that new user came from a particular link and pass in all the data associated with the link. This can happen across install and open. If we have seen the user before, we just match up our cookie to the unique device ID once the user shows up.

The service also comes bundled with a free text-me-the app service which helps pass the link data from a desktop click to the phone and eventually the app.

It's everything that we've always wanted as a linking service for our own apps, plus all the accompanying analytics to measure the performance of your various features. Try it out as it's free. We'd also love recommendations or feedback on how we display the data on our dashboard.

Best, Alex

<comment><USER6> What happens when someone's fingerprint matches up with another? Do they get access to data that they shouldn't have access to?

<comment><AUTHOR> Unfortunately, there is a very low probability of the mismatch until we have effectively seen every device. As our linking service expands, that percentage gets lower and lower. In our experience, the user experience and analytics insight benefit far outweighs the consequence of a mismatch because they are so rare. We encourage our developers not to bundle sensitive data into the links if they use this base case.

If a developer does want 100% match, we have a separate option that can be used with a slightly degraded user experience which pops the browser open really quickly to check the cookie, then returning to the app with the URI scheme.

<comment><USER7> FWIW, Apple has frowned upon the browser cookie check approach and they might reject a submission using it: [http://techcrunch.com/2013/02/25/apple- rejecting-apps-using-...](http://techcrunch.com/2013/02/25/apple-rejecting- apps-using-cookie-tracking-methods-signaling-push-to-its-own-ad-identifier- technology-is-now-underway/)

Do you guys have any estimates as to what the rate of error might be for the fingerprint approach?

Excited to see where you guys are going with this product!

<comment><AUTHOR> Ah interesting. We wouldn't be using it in every scenario, basically only scenarios where we believe there to be a match and want 100% confirmation.

Thanks for sharing!</comment></comment></comment></comment></comment></comment>


Background Jobs with RabbitMQ and Minion - <AUTHOR> http://adam.blog.heroku.com/past/2009/9/28/background_jobs_with_rabbitmq_and_minion/

<comment><USER2> Great writeup, I just implemented delayed job on my development machine last night but I can totally see why I would ditch it in a heartbeat.

Some things I would like to see in the article: * Logging a job * Error handling when a job screws up * Stopping all workers * Clearing the queue * Reading the queue * Queue Priority.

Time to do some more reading I guess.

<comment><USER3> Unfortunately RabbitMQ currently doesn't support message priority (which is in the AMQP spec).</comment></comment>


Windows Explorer Through the Years - <AUTHOR> https://gekk.info/articles/explorer.html <comment><USER2> One thing I find myself missing from Windows Vista/7's Explorer is the tiny media thumbnail in the lower left corner, in the bottom bar. Useful when browsing using the "details" view and going through the list with the keyboard arrows, without bothering with a full preview panel.

<comment><USER3> Download this: [https://msfn.org/board/topic/170375-oldnewexplorer-119/](https://msfn.org/board/topic/170375-oldnewexplorer-119/)

Unpack the RAR file somewhere, open the configuration tool inside, configure as desired but ensure the "Show details pane on the bottom" is enabled. You'll then get an explorer that looks very similar to the Windows 7 style, complete with the exact same Win 7 details pane which frankly is a lot more useful than the basic one in Windows 10.</comment></comment>


What is Debian all about, really? Or: friction, packaging complex applications - <AUTHOR> https://blog.liw.fi/posts/2018/02/17/what_is_debian_all_about_really_or_friction_packaging_complex_applications/ <comment><USER3> The longer I use computers the more I think having an OS-core plus separated user-applications is the way to go. As user I don't care/think a lot about the core, it should just work. Apps should be totally isolated from the base system and be up-to-date. Updating the base should never impact apps, updating apps should never break the base system.

Right now I use openSUSE Tumbleweed[0] and Guix[1] for applications. This gives me an up-to-date OS with the ability to rollback OS updates (thanks to openSUSE snapper and btrfs). Guix is a functional package manager with rollback support & reproducible builds, which allows you to have multiple versions of the same library installed so that different applications can make use of them. The above combination solves a lot of problems traditional packaging systems have.

I also follow to some extend the Snap[2] packaging world. I like the security idea Snap brings to the table, but right now the snap thing is still work in progress.

[0]: [https://en.opensuse.org/Portal:Tumbleweed](https://en.opensuse.org/Portal:Tumbleweed)

[1]: [https://www.gnu.org/software/guix](https://www.gnu.org/software/guix)

[2]: [https://www.ubuntu.com/desktop/snappy](https://www.ubuntu.com/desktop/snappy)

<comment><USER4> I was going to cite Nix in response to this article, but I see you have already mentioned Guix. I hope that both GuixSD and NixOS strike happy balances between the two opposing philosophies described in this article.

</comment></comment><comment><USER5> Lars asks upstream libraries to be careful with API changes. However, Debian doesn't reward this.

Regardless of library track record, Debian pessimistically treats all libraries in Debian stable as if they were OpenSSL of old (which broke API between releases and exposed random internals as potential breakage surface). If you are upstream library developer and maintain perfect API compatibility, Debian still won't ship your releases to Debian stable before the next Debian stable, so app developers can't depend on the new features of your library if they use the system copy. Depending on the nature of the library, this either holds the ecosystem back or leads to app developers bundling the library leading to more untangling work for Debian.

Everyone loses.

<comment><USER6> I've been around this loop before. I've come to the conclusion that it's a fool's errand to try to use Debian-supplied libraries for app development, and that Debian shouldn't bother trying to support it.

Debian-supplied libraries should only be for user-facing applications supplied by the Debian distribution itself. The system copy should be for the system only, and unless you're writing software intended to be part of that system, _it 's not for you_. If you opt in to using it, you've got to accept the trade-off that the rest of the system and all its concerns come first - <USER2> that includes not introducing changes unless absolutely necessary.

I'd much prefer a clear "line in the sand" policy like that than the status quo, which tries to keep everyone happy.

<comment><USER5> I agree with the sentiment for libraries that provide particular computations like parsers for a particular data format.

What about libraries like Gtk, though? Should third-party apps bundle their own Gtk and interface with the system only on the X/Wayland + ATK layers?

What about glibc? Occasionally (getrandom()!) there's new glibc surface that apps really should adopt. Should apps just rely on the Linux syscall interface directly and bypass glibc?

<comment><USER6> The more stable the library, the more accepting the trade-off might make sense to an app developer.

</comment></comment></comment></comment><comment><USER7> I've been reading gnome plant for a while and the recent blog posts about the move to gitlab and how gnome builder can just clone and build gnome apps are pretty promising, in terms of reducing friction.

Debian and distros in general should take note of that.

That said, I think distros (and debian) should look to provide a base system on which we can run flatpaks and containers.

The create a container with a low-friction programming language specific package manager for each project a developer is working on... and publish end- user apps as flatpaks, as these are the only thing people care to update anyways.

<comment><USER8> Debian is running a GitLab server in beta at [https://salsa.debian.org/public](https://salsa.debian.org/public)

<comment><USER7> salsa, really? some people just shouldn't be allowed name things :) hehe

Still cool,

</comment></comment></comment><comment><USER9> I would certainly like a world where the ease of producing a Debian package approaches that of publishing a library in one of the high-level interpreted languages. How likely is that to happen, and what's the best way to package stuff for Debian right now?

<comment><USER10> I am by no means expert, but fpm helps a lot. [https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm)

</comment></comment><comment> xyz-x For desktop, it would seem the homebrew model is very successful. Products and software do get the updates they need; it's based on a pull-request model and when you create a new package you only have to spend a day to go through the syntax linting process in your pull request, as opposed to a year, waiting for a new stable release in a linux distro.

On the server-side, containers is not primarily about "getting the admin out of the way", but about reducing dependencies of your application to their bare minimums. To its extreme you have Erlang and Mirage that would let you compile your whole application to its own TCP-stack + GC + your app, bypassing the kernel completely.

In that world, there's no need for security patches, because you're using a managed fast language (OCaml/Erlang/Elexir/F*) and you don't have things running next to your application that can pose security problems; no shared libraries, no kernel, no SSH daemon; it's all compiled into your app. You get security updates through your language package manager and they are frequent, because you keep your app up to date as you develop it.

Because your above app runs its own GC, TCP-stack and is self-contained, it now makes sense to move to Kubernetes; because it gives you scheduling, health checks, networking (overlay), a resource permission model (RBAC), a network permission model (Calico) and secret management. Your deployment environment is now your operating system, and the distros aren't needed anymore.

<comment><USER11> > In that world, there's no need for security patches, because you're using a > managed fast language (OCaml/Erlang/Elexir/F*) and you don't have things > running next to your application that can pose security problems; no shared > libraries, no kernel, no SSH daemon; it's all compiled into your app.

You're too optimistic. Managed languages solve a few security problems, but not all of them. Logic bugs still exist. Encoding issues still exist. Shellshock still happened. PHP is a managed language and we don't hold it as an example.

The only thing that the lack of shared libraries does is that now, you have to compile the same code into the app. It's going to contain the same errors, but now you have to replace the whole app rather than one library. It's also harder to tell from outside if you're relying on a specific version of a library.

MirageOS provides you with a kernel. You're not getting rid of that one. Also Erlang needs some system to run on. It may hide in the same package and be called Ling, but it's still a kernel.

</comment></comment><comment><USER12> I paid rent as a linux sysadmin for a ~dozen years so of course I have _opinions_ about distros, but in the years since amazon linux has been out I've almost completely left spending any mental energy at that layer behind. And now with containers & kube, I just need like a kernel and init!

I haven't actually read any real detail about it, but my understanding is this is why redhat bought coreos. The old redhat/debian is going to slowly turn into a tarball of static libs for backwards compatibility.

caveat: this is w/r/t "servers" I don't know/care about desktops/laptops.

<comment><USER13> What about security updates to your dependencies in your containers?

<comment><USER14> Update the image and roll out new containers?

<comment><USER15> I think GP is referring to the fact that many containers use e.g. "apt-get" (i.e. the distro package manager) in their build process.

</comment></comment></comment></comment><comment><USER16> Debian works best for languages that haven't standardized on their own easy- to-use package manager. Such as C and C++. Concentrate on that?

If that's not ambitious enough, what would it take for the implementers of a new language to be convinced to just use Debian as their package manager? It seems like that would require a lot of changes.

<comment><USER17> Even those are trying to fix their lack of package managers, conan and vcpkg and the ones getting more love currently.

OS level packages only work properly when developers just focus on a specific OS.

The moment one wants to target as much OSes as possible, building OS specific packages becomes a pain and it is easier to outsource the problem to language specific package managers that abstract the OS layer.

<comment><USER18> I understand this from the developer's perspective - but from a user's perspective, it's horrible UX. I usually don't care much which language the programs I use are written in - however I would very much like a single place where I can view, manage and update all installed packages. This does not work if each package manager keeps its own list.

It also feels ridiculous to have to install another package manager if you only want to have a certain command line tool.

Maybe this could be solved by a sort of meta-standard for package managers, so the OS has at least some way to aggregate all package managers and language- specific packages installed.

Of course, as always with meta-standards, you might fall into the XKCD trap...

<comment><USER19> Containers solve this nicely; developers are free to use their language's package manager to build container images which the user can manage via a single interface. Of course, this means you often have more duplicate code on your disk and the update model changes, but that's alright for me.

</comment></comment></comment></comment><comment><USER20> The git annex developer is more pessimistic about the future of Debian: [https://joeyh.name/blog/entry/futures_of_distributions/](https://joeyh.name/blog/entry/futures_of_distributions/)

<comment><USER21> The Debian processes of package authoring is very complex. I maintain my selection of packages as a private metapackage so that I can "sudo apt-get install ./goktug.deb" and be ready, basically just a list of packages, and even that's complex compared to a PKGBUILD or a BSD port. Recently I wanted to package and maintain Arch Linux's netctl for Debian, and reading the suggested documentation, multiple hours in, having accumulated dozens of tabs of highly- suggested or required reading, I realised I still didn't have a working example package at my hands, and gave up. Furthermore, my packages list had to grow up incorporating more than ten tools specific to making and maintaining Debian packages, _before_ I had even a working prototype of the thing at hand. I'd prefer by far making an RPM or pacman package to that.

Edit: After reading the linked article, I want to add this: I believe things from NPM don't really need to be packaged individually. The community is an outlier in many respects, with its sloppy practices, its very wide scope and the sheer innumerable amount of "packages" it hosts (many hundreds of thousands). For the rest, only the libraries the application software packages (from Firefox to coreutils, anything that's not a library) use need to be packaged. The rest is most often installed by developers or users that are installing non-package software, so they will somehow need to use a third party package manager anyways. The OS package manager does not need to include _everything_ , but what's essential and stable.

<comment><USER11> If you use that metapackage just for installing a list of things you keep as a base system, it may be easier to just keep a list of selections. dpkg --get- selections to get the list, and then to reinstall:

        dpkg --set-selections
        apt-get dselect-upgrade

<comment><USER21> Thanks for the tip! Indeed that's how I use it (see [1]), I want a manually curated list of packages that compose my base system (the packages that I explicitly want installed, not all packages and their dependencies). If using this I can skip the metapackage, that'd be an improvement, will look into it.

[1] [https://github.com/cadadr/configuration/tree/master/deb/DEBI...](https://github.com/cadadr/configuration/tree/master/deb/DEBIAN)

</comment></comment></comment></comment><comment><USER22> Everytime this disccusion comes up I'm missing a major point (so either my very own twisted idea or it's usually phrased in a way I can't comprehend).

So I don't want to say "it depends", but... it depends.

I seem to operating/administrating/using my machines in a certain way, regardless of their official designation as "production/QA/development/just- working-by-chance" \- I have A LOT (say, 80-100%) of packages of the system where I simply care about two things:

a) does it work and

b) is it recent enough to include some features I need.

These are installed by a distro package manager and only get security updates. Everything is awesome.

On the other hand, those 5-20% other packages are usually either not packaged at all in $distro, or too old, or somethings's wrong or I'm really developing against git HEAD. So now the complicated part:

Do I use the latest and greatest version? (Debian unstable, arch/void/other rolling release)

Do I just use the language package manager anyway because will never get packages this year?

TLDR: For all the software (majority) I don't have a laser focus on, I love the distro packages. For some things, the language package manager is fine (or I will use nixpkgs or GNU stow or just plain make install to /usr/local) and for a tiny part I will manually "git pull" every few hours or days and use that. And all of this is not a problem, it works for me[tm].

</comment><comment><USER23> You can also try Snap which works on Debian, I chose it over all the other DEB installers myself. I wrote about it here: [http://visifile.com/visifile/25-jan-2018---why-ubuntu- snap-w...](http://visifile.com/visifile/25-jan-2018---why-ubuntu-snap-will- win-part-1.html)

<comment> old-gregg I sincerely hope that Snap and Flatpack will die.

Linux package management is a rare example of successfully tamed complexity. It's magic: having a single copy of, say, gzip implementation imported and used by hundreds of installed applications.

Sandboxed approach works on servers, where a single machine is usually dedicated to running just a handful of rapidly re-installed apps, it has no place on a desktop. I am not interested of every little component (of which I use dozens) landing with its own "runtime".

this madness is caused by the common techno-disease of seeing a nail everywhere when holding a hammer. yes, containers are great for the (trivial) server use case and no, it's stupid on a desktop which is two orders of magnitude more complicated.

I clicked on your link and saw exactly what I expected:

> VisiFile is a NodeJS application built with Express, Sqlite, and various > NodeJS modules.

yep. another example of wheels coming off: no, NodeJS is not an appropriate tool to build desktop software. by picking the wrong tool you're dragging the wrong deployment model along with it. I will only use an electron-like app if someone pays me for it (Slack at work).

<comment><USER24> Web browsers and Web applications actually completely break the distribution model completely on both ends, client and server. To fix this, you need containerization on both ends.

Chrome and Firefox ship new versions of their products every six weeks. Each version carries both new functionality (Web standards require field trials as part of the standard process), and essential security changes (e.g. for TLS). Ubuntu and Fedora repackage Firefox and ship it as fast as they can, because that is the responsible thing to do, but it would be easier and safer for everybody if that could be done with the transactional updates, parallel version installation and dependency isolation that flatpak and snap can provide.

<comment><USER25> I see this is working for a constantly developing project like browsers. But imagine you just stoped to work on your side project for a year. Now you come back and would just like to add a new feature. You start with updating all your libraries and half of them started to introduce API incompatible changes (the author gave you at least 15 minor releases and three month of transition period but you did not pay attention) and you spent the next two days just with catching up on the development side of things. We did not yet look at all those bugs and security holes which were open in all the libs you used for the last year.

I see a similar friction here we also face between distributions and developers and the main issue for friction seems to be the friction about guarantees for stability. And only after that it extents to the friction about getting the latest version shipped to the user (either developer or end user of an application).

In corporate environments they claimed we solve this all by running microservices and we would just version our APIs to guarantee the stability of our interfaces to our fellow developers. I still would like to see this working for extended period of time in the real world.

I don't see how containers or flatpacks will solve it. At some point someone has to touch it again. Be it for bug fixes, security updates, feature development. If hell breaks loose everytime you've to continue stalled development because something wasn't as stable as expected in your ecosystem we've not solved the problem yet. And it's not solved if we install five different versions of a lib with different sets of bugs in parallel.

</comment></comment></comment></comment><comment><USER26> I may admit that i find the Gobolinux solution interesting.

Basically wrap the language specific managers, and integrate the result into the Gobolinux directory tree.

[https://github.com/gobolinux/AlienVFS](https://github.com/gobolinux/AlienVFS)

<comment><USER21> GoboLinux is incredibly interesting, along with GuixSD and NixOS, which are the three best things to happen in the Linux sphere I guess. GuixSD is my favourite, but it's full GNU, so I can't practically use it (missing drivers in kernel and maybe X, need to compile often). Nix has a funny language and systemd, so not really an improvement over Debian for me. Maybe I should try GoboLinux instead, but I'm afraid that there will be too many packages missing from it and IDK the story with security updates.

<comment><USER26> It is very much a hands on distro, for better or worse.

More akin to Gentoo than Arch, and far removed from the likes of CentOS or Debian Stable.

That said, rolling your own recipes is relatively straight forward. And with the /System/Index they are using these days, i think it should be less sensitive to hardcoded paths and similar idiocies.

</comment></comment></comment><comment><USER27> > after upgrading to the next Debian stable release, my stuff continues to > work

can be replaced by

> with frequent upgrades, errors are sparse blips on the Debian testing > release

-

standard line: if you're considering Debian for the desktop and want a reasonable mix of stability as well as recent updates,

testing recommended over stable.

<comment><USER5> Testing doesn't, by policy, get reliably timely security patches. [https://www.debian.org/security/faq#testing](https://www.debian.org/security/faq#testing)

(I wish Debian had a genuinely supported rolling or rolling-ish flavor. It's bad for the Linux ecosystem when people who don't need to be using out-of-date software use out-of-date software from stable.)

<comment><USER28> "unstable" (ignore the name, assume it refers to the version numbers...) serves this purpose for many.

<comment><USER5> It does for many, but:

1) The general attitude seems to be that if something breaks, the user is at fault for using something called "unstable". I.e. it's not positioned as a way for the casual user to keep using up-to-date software that'd still be smoke- tested enough that you don't need to be an enthusiast who can resurrect an occasional broken system.

2) While there probably in practice is better security coverage than in testing and backports, formally there still isn't security support per [https://www.debian.org/security/faq#unstable](https://www.debian.org/security/faq#unstable) . (I do recognize your HN handle and know you know this, but I'm providing the link for other readers.)

<comment><USER28> > it's not positioned as a way for the casual user

Indeed. Any crazy ideas on how to remedy this? :)

<comment><USER5> Repurposing testing as such a distro (not calling it "testing"). Discontinuing stable (i.e. leaving the enterprise use case to Red Hat and SuSE) if the security team doesn't have capacity to support both.

<comment><USER28> That's a huge ask. My query was really about "rebranding" unstable.

<comment><USER5> When suggesting that Debian provide a security-supported release stream other than stable, the usual response is that the security team doesn't have the capacity to support another one. That why I pointed out unprompted that I'd cut stable if there isn't capacity for multiple security-supported channels. I realize it would be a big change for Debian.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I started using Arch because it just works.

<comment><USER7> Which has same problems... this isn't really about debian, but distributions in general.

<comment><USER30> The current solution for rust or go applications seem to be just packaging the resultant binary even in the repositories. I don't know if they will ever ship rust libraries as packages.

<comment><USER31> I'm a mere user of Arch so I don't know what the official policy is, but from where I'm standing, it looks like---at least for the community repo---the policy is "do what works." You are indeed right that Go and Rust applications are packaged as-is without having all of their corresponding library dependencies packaged as well. But, for example, Haskell applications like pandoc _do_ have all their libraries packaged. Compare the output of, say, `pacman -Si docker` and `pacman -Si pandoc`.</comment></comment></comment></comment>