gnoway

Looking at Mr. Niedermeyer's linkedin profile[0] and what he's doing/where he's worked was kind of enlightening as to his purpose and motivations.

It probably works for him, though. I think 99+% of people, myself included, do not often look at who is writing what they read online. And I'd guess a majority percentage don't think about the fact that they are reading opinion vs. news.

[0] https://www.linkedin.com/in/edward-niedermeyer-35942261

Did you read the blog post? It would need to be at least two decent mobile apps.

You can see it however you want :). You're also free to set up your own DNS if you prefer; we don't assert any control over the design, just our implementation.

Well, it's ours. We created it. We've allowed other countries to use it because it benefits us to do so.

I realize this is probably not the popular opinion, but I'm not sure it makes any sense really to give up control over it.

Has anyone used this successfully who would like to comment on it?

We ran a brief test about a year ago and found performance was not acceptable given the amount of hardware dedicated to the test cluster, which they set up for us to their specifications in their hosting facility after multiple in-house attempts were disqualified post-completion (...a frustrating waste of time) by their SE. I'm not sure how fair we were with the workload we designed for the test; Our management seemed to think this was going to be "Easy Scale Out Big Data MSSQL!" but I came away thinking this was not a product you could just port an existing application to and be done with.

Be honest. If you were President of YC and you got invited, wouldn't you attend?

I disagree. I think it's more likely that we're still using programs designed for a different era.

For example, food stamps (SNAP) were made permanent in 1964 as one of the great society programs. WIC came a few years later. I suspect - but have not researched - that you will find this is true for a lot of current welfare programs.

There may be people in power making bad decisions about administering these programs, but I don't believe they were designed to ensnare.

Well I thought it was obvious, but my reply was intended to be sarcastic. For it to be taken at face value by anyone kind of highlights the problem with the systemd approach, IMO.

Certainly not everyone. There's a whole host of people who are angry about systemd the project primarily because of the (maybe misunderstood) behavior and communication from systemd the development team.

Personally I don't see what everyone is so upset about here. As pointed out by message 15, they've simply changed the default behavior and provided a long-opt setting to restore the old behavior if required; the hundreds or thousands of people who don't closely follow systemd will just be inconvenienced temporarily until they figure out wtf is going on, then they are back in business. And, maybe next time they'll pay closer attention.

Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client.

If you automatically throw out cases, what's the point of having a law enabling and encouraging those cases in the first place? Or maybe a better question is: what would legitimate infringement look like, if what Google did is fair use?

I don't know if APIs should be subject to copyright or not. I certainly don't want them to be. But since APIs have been found copyrightable, it's hard to understand how this wasn't open and shut for Oracle.

I thought this part of an Ars Technica article[0] on the trial was pretty telling:

"On cross-exam, a Google attorney brought up a graph from an internal presentation by Brenner showing "aggressive" and "conservative" estimates of what would happen to Java licensing revenue from 2007 to 2010. The graph's "aggressive" line showed a decline from around $140 million per year to about $105 million, and the "conservative" line showed a decline from the same starting point to around $50 million.

The graph was created before the launch of Android. Google's point was clear: Java was in decline, Android or no Android—and its executives and salespeople knew it."

It doesn't really matter what the numbers were though. They would have been higher had Google paid Sun for a Java license.

[0] http://arstechnica.com/tech-policy/2016/05/suns-head-of-java...

Serious question: what caused you to purchase a Voyage vs. an Oasis or regular Paperwhite Kindle?

I don't know what parent is talking about w/ README files. But Slackware Linux (slack... get it?) includes a link to the church in their install.end file. They started scrambling it in a recent release.

I think he meant that they might not have one.

It's been a while since I looked at using ZFS for anything meaningful, but at the time (~6 years ago), while losing L2ARC was no big deal, losing dedicated ZIL was catastrophic. I think that's still true today.

So you need at least two ZIL devices in a mirror. On top of that, you really need something faster and lower latency for your ZIL vs. the ARC or main pool; people were trying to use SSDs but most commonly-available drives at the time would either degrade or fail in a hurry under load. So the options were RAM-based, e.g. STEC ZeusRAM on the high end, or some sort of PCI-X/PCIe RAM device. The former was not easy or cheap to acquire for testing stuff, and the latter made failover configs impossible.

I think that ZIL is also not soaking up all writes, just most writes meeting a certain criteria. Some just stream through to the pool. So I was always thinking of it as a protection device that also converted random writes to sequential. Some people don't think they need that.

I remember the fragmentation issue being a problem at the time, but also thinking it was probably going to get solved soon because there was so much interest and a whole company behind it. Then Oracle happened. My guess is that if it were still Sun and all the key people were still there, this would be a solved problem right now. As it is, Oracle probably wants you to buy all the extra storage anyway, and would love to offer professional services to get you out of the fragmentation bind you're in.

Earth is elliptical - an oblate spheroid - so I would say they can.

He meant one 1080 is faster than two 980s in SLI, but that seems pretty hard to believe; we're going to need to wait for some 3rd party reviews.

The AMD Radeon R9 Fury series has a 4096bit bus (HBM1) - it's been out for months - so it would already be shaking it up if so.

Except they even state:

"If you’ve pushed a gem with internal code, you still need to reset API keys, URLs, or anything else sensitive despite the new behavior."

And:

"...we’ve been using an Amazon S3 bucket to store the gems for years now with versioning on - so if someone does remove gems that are necessary, we can easily restore them."

So what they've really done is given developers the illusion that the unwanted gem has been removed, while introducing the ability to break everyone's workflow just like npmjs. In some ways this is worse than before; devs still need to change secrets, and if it's non-secret sensitive code they are concerned about, it's still 'out there' and the dev still has to trust that the rubygems.org people don't do something unwanted with it.

How is publishing a secret (I mean passwords, ssh keys, etc.) a copyright violation?

I think the key is that crates.io (and rubygems.org, nuget.org, etc.) as repo owners have to own the removal operation themselves and not delegate that to the package owner/maintainer. The repo owner is better positioned to take package consumers' needs into account and make good decisions about when and how to remove a package.

As far as satisfying support requests: obviously exceptional stuff like DMCA gets handled, but package owners publishing keys, etc. is still their responsibility and shouldn't accelerate or even guarantee removal IMO. If you publish secrets, it's not crates.io's responsibility to help you hide that mistake, and you need to be changing those secrets anyway.

Package persistence is not really a dependency manager feature though, it's a package repository feature. npm didn't fail; npmjs.com did.

I'm just waiting for this to happen to bower next. AFAIK they're just a registry pointing to github. All it's going to take is someone doing a force push without thinking and we're in this same situation again.

Charlie Stross submitted[0] a link to a post on his blog[1] touching on this last month.

[0] https://news.ycombinator.com/item?id=11373605

[1] http://www.antipope.org/charlie/blog-static/2016/03/follow-t...

Presumably it would be an ownership group like e.g. Tim Cook + some other people borrowing the money, and/or they'd partner with a P/E firm. Isn't that what Dell did a couple of years ago?

Have you ever noticed that wherever you point a firehose, the target tends to get soaked as soon as you turn the water on?

This is about a hair dryer, not their hand dryers.

We have had problems but mainly with plugins. There's basically no mandatory QA process for plugins, nor is there any facility to make it obvious to an updater that an upstream change affects a downstream plugin and might break it.

In my opinion, Jenkins is a product that you really need to have a test instance for, where you either have copies of your builds or you've set up some 'unit test'-type builds to exercise functionality you depend on.

I would consider getting some sleep.

I agree with your point about the emotional involvement, but honestly, this is an unemployed former car salesman and restaurant manager. For him to think he's legitimately negotiating release of hostages over twitter and skype... sure, maybe, but it falls into the 'requires extraordinary evidence' bucket for me.

This reply was sufficiently aggravating to make me go do some research.

Here's a thread[0] from last year bringing up some issues with KeePass2 code. It also links to an audit by some group that appears to be involved in information security for the French government[1]. It's in French. The HN comment asserts the audit found KeePass2 2.10 portable to be safe; I don't comprehend French so I don't know what the audit says.

The documentation[2] specifies that the default KDF uses 6000 rounds of AES, although that is configurable, so presumably 'hahaha...extremely fast cracking speeds' could be improved to 'fast cracking speeds' or even 'moderate to slow cracking speeds'.

KeePass has had one published vulnerability[3]; it applies to KeePass v1.17, so should not be a concern anymore.

I will continue to use KeePass2.

  [0] https://news.ycombinator.com/item?id=9727297
  [1] http://www.ssi.gouv.fr/uploads/IMG/cspn/anssi-cspn_2010-07fr.pdf
  [2] http://keepass.info/help/base/security.html#secdictprotect
  [3] https://www.cvedetails.com/product/23054/Keepass-Keepass.html?vendor_id=12214

Well, Delphi can call functions in external assemblies so...technically?

https://rosettacode.org/wiki/Call_a_function_in_a_shared_lib...

In case anyone's looking here first, ISOs are available here:

http://releases.ubuntu.com/16.04/

For some reason these are not linked yet from the 'Downloads' page at ubuntu.com.