Meltdown and Spectre Linux kernel status - <AUTHOR> http://kroah.com/log/blog/2018/01/06/meltdown-status/ <comment><USER2> One thing I'll reiterate: as Greg mentioned, the backports to kernels prior to 4.14 are derived from a rather old KAISER version. They do not match what 4.14 and 4.15 do. This has several consequences.

1\. They will have bugs. There's a reason PTI was heavily modified from the old KAISER code. They will also tend to diverge from upstream just because the code is so different. This means that the next time low-level x86 changes need to be backported, it'll be a huge mess.

2\. There is only minimal upstream support. I, for example, am already largely ignoring two bugs in the backports that aren't in the upstream version. Why? Because I have no affiliation with a distro using an old kernel.

3\. Contrary to its marketing, KAISER does not effectively mitigate the old kASLR leaks. PTI very nearly does, and I intend to improve it further once I find some time to do so. I doubt those improvements will get backported to pre-4.14 kernels.

4\. At least some versions of "KAISER", on meltdown-affected hardware, expose the kernel stack to userspace. If that's not usable for rooting a box, I'll eat my hat. KPTI doesn't have this problem.

If you can put pressure on your organization or suppliers to update to 4.14 or better, please do so. Red Hat, especially, should seriously consider moving to 4.14 for RHEL 8.

<comment><USER3> As far as I can tell, the RHEL/CentOS kernel has mitigations not only for Meltdown but also Spectre (using the new MSRs).

Am I right in assuming that Red Hat built their own mitigations, independently from upstream?

<comment><USER4> The patches on RedHat 7.4 have impact on performance and capacity for a Load Balancer type of workload, see [https://www.spinics.net/lists/stable/msg209193.html](https://www.spinics.net/lists/stable/msg209193.html)

</comment></comment></comment><comment><USER5> FYI, Red Hat (and CentOS) already have updated kernels with mitigation.

And that made me asking how Red Hat (and the free derivative CentOS) could have already patched their current kernel (on Jan 4th) while the patch was still being discussed on kernel ML the _same day_?

I don't see how they could come up with new kernel with mitigation for the three variants, excellent KB articles on the CVEs, tunables flag, preliminary performance test, etc. without having already patches implemented and tested for some time.

Do they have internal kernel devs? And so, do Redhat have another implementation?

(This is my first comment on HN, I hope I'm following adequately the guidelines)

<comment><USER6> There's such a thing called: 'embargo period', wherein CVEs are (in most cases) responsibly disclosed to various parties---including several Linux distributions---much ahead than the general public, to coordinate security errata.

So you can be assured that Red Hat coordinates with upstream. It also has a serious "Upstream First" policy (with sensible exceptions, of course).

As to whether Red Hat has kernel developers, of course it does. :-) Much of Red Hat's popularly began as a _Linux_ distribution. If you're curious, the LWN publishes statistics about who contributes to the Linux kernel, and the most recent one is for the 4.11 development cycle -- [https://lwn.net/Articles/720336/](https://lwn.net/Articles/720336/)

(Disclosure: /me is a Red Hatter.)

<comment><USER7> I really dislike the term "responsible disclosure" in this context. I might consider it responsible to notify a software vendor about a vulnerability in their software so they have a chance to issue a fix to their customers before the rest of the world finds out. But this situation is different. These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just _preferential_ disclosure.

<comment><USER8> > These vulnerabilities affect everyone, and only a special few were allowed > to prepare in advance. That's just preferential disclosure.

In this particular case, most of the fix had to be done in the operating system (the new microcode only enabled extra functionality needed by part of the operating system fixes), so it makes sense that operating system developers were allowed (and required) to prepare in advance. The three most relevant operating systems are Windows, OSX, and Linux; for Linux, one of the most important distributors is Red Hat. That gives two of the groups which were notified in advance: hardware (Intel, AMD, ARM) and operating systems (Microsoft, Apple, Red Hat, a few others).

<comment><USER9> Ubuntu and BSD still have no fixes. It indeed seems like a preferrential disclosure. Plus no 2nd-tier cloud providers like DO were notified.

<comment><USER10> It will be pretty unfortunate if it turns out that the projects that maintain a kernel (FreeBSD, various others) only received notification at Christmas, while various Linux distros (who have to deal with packaging, release, QA but not developing their own kernel patch since that comes from upstream) got a long warning period. It seems that way... Looking forward to reading about how this played out when the dust settles.

<comment><USER11> There was a post to OpenBSD- tech list telling no BSDs were told anything. And a blog post from Canonical says that the patch will be available 9th January (IIRC).

<comment><USER12> OpenBSD didn't respect the embargo a few months ago with the wifi issue, no surprise that they weren't told about this up front.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > As for how this was all handled by the companies involved, well this could > be described as a textbook example of how NOT to interact with the Linux > kernel community properly. The people and companies involved know what > happened, and I'm sure it will all come out eventually

I'm looking forward to that story.

<comment><USER14> I'll eat my hat if it isn't some version of "here is a giant patch set we never worked through the chain nor asked about at all please make it your problem to mainline it immediately, followed by, well, a good old fashioned LKML go fsck yourself."

</comment></comment><comment><USER15> What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model.

Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this machine's life?

BTW, my machine is just a normal desktop/laptop, so no server stuff running or expected.

<comment><USER16> The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs _inside your central processor chip_ , the so-called _microcode_ , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW).

Firmware updates are largely irrelevant to this issue, only being involved in the sense that one way to perform _microcode_ updates is for your machine's firmware to upload the new microcode image file. But that is just _one_ way for that to be done; your operating system can do it, too.

* [http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

* [https://news.ycombinator.com/item?id=16081366](https://news.ycombinator.com/item?id=16081366)

* [https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...](https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf) ([https://news.ycombinator.com/item?id=16079910](https://news.ycombinator.com/item?id=16079910))

<comment><USER17> Windows, at least for right now, does not seem to be updating CPU microcode during boot. If you run the PowerShell Get-SpeculationControl script that gives you the status of the updates it states that the CVE-2017-5715 fix requires hardware support. If you don't have it you are told to get a BIOS update from your OEM. WIthout it, the status for CVE-2017-5715 is listed as not enabled due to missing hardware support.

Of all of my computers only one has been issued a BIOS update so far. I ran the PowerShell script before and after installing the BIOS. Installing the BIOS flipped the status of the fix for CVE-2017-5715 to on.

I also ran the free HwInfo utility that will show the microcode revision before and after installing the Windows update and before and after installing the BIOS. It only ever changed with the BIOS update.

I hope this changes and Windows does start updating CPU microcode. I also have a few older motherboard's that aren't likely to ever see a BIOS update again.

<comment><USER18> This appears to be my experience too. I'm checking a few VMs and they are showing as missing hw support.

Do note that Microsoft appears to have updated their doc in the last day or so. They are now saying that three registry settings need to be set (instead of 2 previously).

      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
      reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
      reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

Some quick Googling seems to indicate that Windows has the ability to update microcode.

[http://forum.notebookreview.com/threads/how-to-update- microc...](http://forum.notebookreview.com/threads/how-to-update-microcode- from-windows.787152/)

Maybe this will happen with a later update from Microsoft as I'm doubtful that BIOS updates will happen with at least one of my systems.

<comment><USER19> MinVmVersionForCpuBasedMitigations is for VM/Hyper-V: [https://docs.microsoft.com/en-us/virtualization/hyper-v- on-w...](https://docs.microsoft.com/en-us/virtualization/hyper-v-on- windows/CVE-2017-5715-and-hyper-v-vms)

</comment></comment></comment></comment></comment><comment><USER20> I use AWS instances (multi-tenant). I understand that by now AWS hypervisors have been patched.

Does that fully protect my unpatched AWS instances from this CPU-level issues?

If not, is there any way to protect my AWS instance from a rogue unpatched attacker instance running on the same hypervisor?

In other words, with the current CPUs deployed at AWS, will it be possible for an attacker to simply launch an unpatched instance to steal data from other instances (patched or not) running on the same AWS hypervisor?

I hope not, because the cloud multi-tenant model would be effectively dead until AWS hosts with unaffected CPUs are available.

<comment><USER21> No. The "master" software fix to Meltdown keeps userland and the kernel from trivially sharing kernel memory pages. If your guest kernel doesn't have this fix applied, then your guest userland shares pages with your guest kernel, and guest processes can dump kernel memory.

<comment><USER22> In theory it should be possible for a hyper visor to retrofit a fix into a guest, but it's messy and I doubt anyone will ever do it. Could be fun though.

Quick sketch: disable EPT and go back to shadow paging. Maintain a third page table with any kernel pages unmapped. Invisibly swap between on syscalls.

<comment><USER23> This sounds really slow to me. What is the overhead of "disable EPT and go back to shadow paging", or what was the performance win of EPT?

</comment></comment></comment></comment><comment><USER24> What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. The 20171215 update carried by some distros only seems to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed, are they covered by the 20171117 update, or are the new microcodes simply not ready for all models yet?

Of course, the microcode updates are meaningless without the corresponding kernel patches, but apparently only RHEL and SLES were deemed worthy of receiving those ahead of time, having already rolled them out while Linus and co are left scrambling to integrate the IBRS and retpoline code dumps after the fact.

[1] [https://tracker.debian.org/news/899110](https://tracker.debian.org/news/899110) [2] [https://downloadcenter.intel.com/download/27337/Linux- Proces...](https://downloadcenter.intel.com/download/27337/Linux-Processor- Microcode-Data-File)

<comment><USER24> Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes.

I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]).

[1] [https://patchwork.kernel.org/patch/10147547/](https://patchwork.kernel.org/patch/10147547/)

</comment></comment><comment><USER25> Reading between the lines, it seems this is a pretty colossal fuckup by Intel; both in terms of the bug but especially how it was handled.

<comment><USER16> You do not need to read in between the lines to learn that; several commentators have come right out and said it.

* [http://lists.dragonflybsd.org/pipermail/users/2018-January/3...](http://lists.dragonflybsd.org/pipermail/users/2018-January/313758.html) ([https://news.ycombinator.com/item?id=16084641](https://news.ycombinator.com/item?id=16084641))

* [https://medium.com/@frankycaron/this-week-in-words-the-langu...](https://medium.com/@frankycaron/this-week-in-words-the-language-of-meltdown-and-spectre-126bf109e5c5) ([https://news.ycombinator.com/item?id=16075588](https://news.ycombinator.com/item?id=16075588))

* [http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...](http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/)

One of them you might have expected to use the word "fuck", but actually did not. (-:

* [https://lkml.org/lkml/2018/1/3/797](https://lkml.org/lkml/2018/1/3/797) ([https://news.ycombinator.com/item?id=16066968](https://news.ycombinator.com/item?id=16066968))

In part, this was down to the cat being let out of the bag early.

* [https://news.ycombinator.com/item?id=16080918](https://news.ycombinator.com/item?id=16080918)

* [https://news.ycombinator.com/item?id=16068510](https://news.ycombinator.com/item?id=16068510)

<comment><USER26> If those 4 extra days of embargo would not have caused a total PR disasters on Intel's side will eat my socks. This wouldn't have become any better given another week of time.

<comment><USER27> The fact that Intel is rumored to have know about this since _June_ lends credence to your belief, however if that week would have let OS vendors have updates ready, and cloud providers already patched, then it _would_ be less of a disaster. There's a certain amount of flailing about when details are released earlier than expected, and vendors don't have a answers or instructions prepared.

</comment></comment></comment></comment><comment><USER28> From my cursory reading I understand it is a cleverly orchestrated timing attack.

In other words, if something would need 500 picoseconds you have bit 1, if it is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air).

This is made possible because processors execute the read speculatively even if it is actually forbidden. This read causes a cache hit. Of course the read is never brought into effect because first it is forbidden and second it is in a branch which will never be executed. At the time of the speculative read the CPU seems not to have enough information to know not to execute that read. Even speculatively.

And that speculative read has a side effect on the cache which is measured by the exploit.

Of course the read is never made visible to the process because later the CPU knows not to bring it into effect. However then it is too late: there is measurable difference in caching times.

Did I understand the way of the attack correctly?

<comment><USER16> Timing the L1 cache response for speculatively fetched data that one could not normally access is _just one_ of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions.

* [https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...](https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/) ([https://news.ycombinator.com/item?id=16080002](https://news.ycombinator.com/item?id=16080002))

* [https://dev.to/isaacandsuch/how-meltdown-works-28j2](https://dev.to/isaacandsuch/how-meltdown-works-28j2) ([https://news.ycombinator.com/item?id=16085592](https://news.ycombinator.com/item?id=16085592))

One of the _other_ problems is tricking the branch predictor into speculatively jumping into code of one's choosing.

* [https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...](https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf) ([https://news.ycombinator.com/item?id=16079910](https://news.ycombinator.com/item?id=16079910))

<comment><USER29> > One of the other problems is tricking the branch predictor into > speculatively jumping into code of one's choosing.

But to read the data one still must use timing attacks, no?

</comment></comment></comment><comment><USER30> > If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, > and you do not have a distribution supporting you, you are out of luck.

So, if you are running a (still supported) Debian Jessie a simple _apt-get upgrade_ isn't gonna cut it:-(

<comment><USER16> As the Debian announcement says:

* [https://lists.debian.org/debian-security-announce/2018/msg00...](https://lists.debian.org/debian-security-announce/2018/msg00000.html) ([https://news.ycombinator.com/item?id=16076175](https://news.ycombinator.com/item?id=16076175))

It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-:

* [https://news.ycombinator.com/item?id=16076660](https://news.ycombinator.com/item?id=16076660)

<comment><USER30> I'm not pointing at Debian. I think it is even possible to run Jessie with a current kernel, (which is quite cool) but I haven't tried it. I just upgraded all machines to Stretch and called it a day.

I just did the _apt-get update; apt-get upgrade_ dance in a hurry yesterday and thought I might be good. My post was more a reminder to everyone not be lulled into a false sense of security...

<comment><USER31> I run (many) jessie systems with 4.9 kernels (still haven't made a 4.14 configuration). No problem at all.

<comment><USER32> You might want to bite the bullet and upgrade from 4.9, because the patches for 4.9 are not so rock solid: [https://news.ycombinator.com/item?id=16087736](https://news.ycombinator.com/item?id=16087736)

</comment></comment></comment></comment></comment><comment><USER33> Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?

<comment><USER34> Essentially yes, the exploits require code running on the machine that's attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector.

It's also strictly speaking not a privilege escalation, it's "see things you're not supposed to.", such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.

<comment><USER33> > JavaScript ... is a demonstrated attack vector

OMG, I didn't know that. Thanks.

<comment><USER35> It also consumes lots of CPU to scan memory this way, so just be on the lookout for webpages consuming lots of unexpected CPU.

<comment><USER36> In the age of fancy JavaScript webapps, this seems laughable. 2 or 3 tabs in Chrome is enough to turn my laptop into a space heater.

</comment></comment></comment></comment></comment><comment><USER37> With so much going on - is there a way in linux to know whether my system is patched or not?

Similar to the powershell script for Windows?

<comment><USER38> A number of ways are listed here [1]

1\. With dmesg

dmesg -wH | grep 'page tables isolation'

2\. With /proc/cpuinfo

grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!"

[1] [https://askubuntu.com/questions/992137/how-to-check-that- kpt...](https://askubuntu.com/questions/992137/how-to-check-that-kpti-is- enabled-on-my-ubuntu)

<comment><USER37> Thanks. So apparently, my system:

      Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64)

is unpatched! Is it because of LTS version? Most servers run this including mine.

<comment><USER39> Ubuntu say they will release a patch on or before the 9th of January.

They got caught out by the embargo being ended early.

</comment></comment></comment></comment><comment><USER40> Based on the remarks I'm wondering if there's a distribution out there that is similar to Ubuntu LTS but only uses LTS kernels.

I'm on CentOS right now and love it, but from what I've understand so far it would be preferable to be on a newer kernel.

I was planning to look at Ubuntu LTS and while they do have updated kernels available they seem to ignore LTS: [https://wiki.ubuntu.com/Kernel/LTSEnablementStack](https://wiki.ubuntu.com/Kernel/LTSEnablementStack)

Also, 18.04 will be based on 4.15 which doesn't make sense to me.

Debian stable maybe?

EDIT: I know I can install updated kernels but I'd rather stick with what a core distribution provides if possible

<comment><USER41> Actually, Ubuntu created the term "LTS" in 2006, for Long Term Support releases. Greg started using the term himself just a couple of years ago.

<comment><USER40> Re-reading my post it does sound a bit confusing.

What I meant is: Ubuntu LTS seems to not give a damn if the kernel they use is also an LTS release.

Examples would be: 14.04, 16.04 HWE kernels, 18.04 (currently planned to be 4.15).

</comment></comment></comment><comment><USER42> We applies it to the bare metal DB servers for my.zerotier.com and there is definitely a detectable increase in IO cost. Reducing syscall overhead is going to become even more important.

</comment><comment><USER43> What about Ubuntu users? Is the update our already?

<comment><USER44> Not yet - keep an eye on their wiki page for Meltdown/Spectre:

[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...](https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown)

</comment></comment><comment><USER45> I've been thinking about some of this. A possible design to prevent some of these issues would be to read all protected memory, in speculative execution paths, as dummy all-zero bits value, and not put anything into the cache. I.e. no actual access takes place to any protected area and no breadcrumbs are left in any CPU storage such as a cache. (Then if that path is actually taken, generate the exception).

The whole problem is that the kernel/user protection is just a sham that is not being taken seriously by the CPU implementation. It allows access to take place without a proper mode change. Basically the whole fetch-decode-execute machinery (all of its pipelines, caches, registers and other areeas) should be regarded as untrusted and prevented from accessing or storing anything unauthorized according to the current security state of the CPU.

<comment><USER46> The kernel/user enforcement by the CPU is a sham (kinda) in Intel CPUs when the data you want to access is in L1 (people are guessing). This is only for the meltdown issue.

Spectre doesn't care about kernel/user at all. So even other CPUs are susceptible. Every CPU that speculates is vulnerable in theory.

</comment></comment><comment><USER47> Is the clock still ticking on Joyent.com patching their public cloud (illumos, SmartOS)?

[https://help.joyent.com/hc/en- us/articles/115015938847-Secur...](https://help.joyent.com/hc/en- us/articles/115015938847-Security-Advisory-Intel-Security-Findings)

</comment><comment><USER48>
        If your Linux systems are running a normal Linux
        distribution, go update your kernel. They should
        all have the updates in them already.

I use Linux Mint and have not seen any recent kernel updates.

Which kernel version is considered safe?

<comment><USER49> > I use Linux Mint and have not seen any recent kernel updates.

If you're not aware Linux Mint turns off kernel security updates _off_, you need to check by hand.

<comment><USER50> I always preferred Mint for desktop Linux. I knew they had a poor security record due to their HTTP downloads at one time, but no kernel security updates is news to me.

If you must use desktop Linux, I guess I'll be recommending Ubuntu from now on. In my testing Mint and Ubuntu both work pretty well out of the box on lots of different hardware configurations unlike other distros. But learning this really tips the scale, Ubuntu or bust.

<comment><USER51> A great advantage of linux is allowing the end user choice of distribution and desktop environment to find their specific needs. Unfortunately, not all choices are good. I wish Mint would go away.

</comment></comment></comment></comment><comment><USER52> A good way Intel could say sorry is to have a new generation hardened cpus at a good price.

<comment><USER32> Even offering ECC for mere mortals would be a good start. Of course with the option to disable as much of the ME as possible.

</comment></comment><comment><USER53> So if you're running a ARM64 chromebook, the answer appears to be: get fukt.

"For the 4.4 and 4.9 LTS kernels, odds are these patches will never get merged into them, due to the large number of prerequisite patches required. All of those prerequisite patches have been long merged and tested in the android- common kernels, so I think it is a better idea to just rely on those kernel branches instead of the LTS release for ARM systems at this point in time."

Great. Into the trash it goes.

</comment><comment><USER54> This just reminded me: when will Ubuntu (and Debian?) fix apt's broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal "apt update; apt upgrade" on any of our machines, it's always "the following updates have been held back" and then it's time to manually use dpkg to install the relevant updates.

<comment><USER55> "apt full-upgrade" will upgrade everything. It may also remove packages to fix higher priority dependencies, though I've never seen this happen in real life.

<comment><USER56> Happened to me yesterday with my Proxmox host. It wanted to install firmware- linux-free, which conflicted with pve-firmware. It decided it wanted to remove pve-firmware which would also completely remove proxmox-ve... Had to upgrade with --no-recommends.

</comment></comment></comment><comment><USER57> The website serves JS and does not serve it over https, and discusses Spectre bug and how to patch it. I know he is the second most important guy on linux, but the irony.

<comment><USER58> And you probably know much better than the second most important guy on linux what security means on the Internet: securing some javascript script on a random blog.

<comment><USER59> HTTPS should be expected by now - ISPs keep messing with my unencrypted traffic.

<comment><USER33> Then you should get yourself a different ISP or a VPN.

<comment><USER60> This is an extremely easy thing to say for many people around the world.

But for a large number of people - Americans, folks in countries with monopolies or state manipulation of internet traffic - it is not.

Not everyone has a different ISP to choose from. VPNs are a risky proposition and can significantly reduce bandwidth and increase latency.

<comment><USER61> Anyone that thinks ISPs don't mess with traffic, should check out this malware research

[https://www.virusbulletin.com/conference/vb2017/abstracts/la...](https://www.virusbulletin.com/conference/vb2017/abstracts/last- minute-paper-finfisher-new-techniques-and-infection-vectors-revealed/)

</comment></comment></comment></comment></comment></comment><comment><USER62> I'm out of the loop but I heard it's the white hat hackers who exposed the flaw (probably they were at Google?).

Is the exposition carefully publicized so the flaw is not exploitable by malicious hackers?

Or does Project Zero expose everything, and a malicious hacker can read it and create code that spreads over the internet to harm computers?

I hope it's not the second case because that should cause global panic.

<comment><USER63> It's closer to the second, but:

1) the vulnerability is local, not directly tied to spreading as malware (but these days placing JavaScript in an ad is easier and possibly more effective than a virus...)

2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter.

<comment><USER62> > 2) there is no such thing as "exposition carefully publicized so the flaw is > not exploitable by malicious hackers". Just assume that black hats are as > smart as white hats or smarter.

You're missing the point. Not doubting the smartness of black hats, white hats likely took their time to discover the flaw. If you make the details public in a controlled manner and then announce the fixes shortly after, you essentially did not give black hats enough time to fill the missing pieces of the public announcement.

For instance, in the extreme case, the statement "we have discovered a flaw at the hardware/CPU level in such and such chips, and we call it meltdown and spectre", it's pretty obvious the black hats would have no clue what it is. (They may have already discovered it on their own, and may have named the flaws something completely different. Even then they wouldn't know if white- hats discovered what they discovered.)

<comment><USER64> For one thing, the fixes are up in the Linux kernel for anyone to see.</comment></comment></comment></comment>


IKEA to sell furniture that can wirelessly charge your phone - <AUTHOR> http://www.cnet.com/news/ikea-to-sell-furniture-that-can-wirelessly-charge-your-phone/

<comment><USER2> Most devices I bought from Ikea failed - clocks run slow 3 out of 5) lamps fail to turn on (2 out of 3), and flicker when they do. I don't see myself ever buying anything electric from that shop.

<comment><USER3> Maybe all of your other clocks run fast?</comment></comment>


Problems with crypto market capitalization metric and potential solutions - <AUTHOR> https://medium.com/chainrift-research/chaff-from-the-wheat-towards-improved-cryptocurrency-valuation-metrics-2e347a93f8e2 <comment><USER2> This is a poor quality article with lots of weird assertions.

> "All new forks initially inherit their parent blockchain's market cap, > regardless of their own merit, value, utility, initial uptake, use, > liquidity, etc."

Forking a coin in no way assigns any monetary value to it. It can't even have a real market cap until it's price is set by market demands. The only part of market cap that gets carried over is the supply.

"...anyone who can trivially fork Bitcoin (and get their shiny new shitcoin listed on an exchange) to create an alt-coin with apparently equal valuation to BTC. This works at least for a time, until other longer-term market forces inevitably act to bring the new asset into a more realistic valuation"

Weird to mention that forking is trivial in the same sentence (and condition) as getting it listed on an exchange. Getting a coin listed on a legitimate exchange is extremely non-trivial. And again it would not have equal valuation. It has no valuation until the market demands it.

<comment><AUTHOR> I have updated the wording of the original article to further clarify the nature of coin inheritance as it pertains to market cap.

The remainder of the article remains largely unaffected by the original poor choice of words regarding market cap inheritance.

As for the quality of the article, I beg to differ. Alot of time went into its research and presentation. Additionally, it was reviewed by a number of active crypto-researchers (as well as yourselves) and revised according to feedback.

Thank you for taking the time to read and leave comments, which have led to improvements to the ideas expressed in the article.

<comment><USER2> Thanks arbitcoin! Refreshing to see feedback taken to improve content even though I was a bit harsh. That's a great personal attribute that leads to growth and mastery, I wish most people were like that.</comment></comment></comment>


Haystack halting testing because of security concerns - <AUTHOR> http://blog.austinheap.com/haystack-halting-testing

<comment><USER2> A nice summary has been posted on MetaFilter:

<http://www.metafilter.com/95686/Needle-program-exchange>

In particular, one of the commenters claims to have analyzed Haystack and found some very scary things:

[http://www.metafilter.com/95686/Needle-program- exchange#3280...](http://www.metafilter.com/95686/Needle-program- exchange#3280621)

<comment><USER3> Interesting. That's a post by Jacob Applebaum who works on Tor. His Twitter feed is full of his thoughts about Haystack: <http://twitter.com/ioerror>

</comment></comment><comment><USER3> Good. They need to engage people and go for the openness and transparency. Otherwise I'd be seriously concerned about the security of this project.

I couldn't find a reference to the 'vigorous debate' mentioned. Can anyone point to relevant security mailing lists where Haystack is being discussed?</comment>


Server Side Upgrades - <AUTHOR> http://blog.alexmaccaw.com/server-side-upgrades

<comment><USER2> I disagree with the author. Backwards compatibility is one of the great things about Microsoft's stuff, not a bad thing. In 6+ years at Loopt, an upgrade (to get new shiny features) never meant we had to stop using older code.

SQL 2012 is nearly completely[1] compatible with SQL 2005, and largely compatible with SQL 2000. IIS 7.5 will still run ASP code in VB from the early 2000s, and that code can live alongside ASP.net 1.1-4, or ASP.net MVC 1-3. In many cases, you can even have hybrid ASP/ASP.net/MVC combined applications.

There are often benefits that make revisiting your old code worthwhile, but rarely are you forced to. And we kept getting security updates back-ported the whole time.

      [1] http://technet.microsoft.com/en-us/library/ms143179(v=sql.110).aspx
      [2] http://learn.iis.net/page.aspx/727/classic-asp-applications-on-iis-overview/

</comment><comment><USER3> The financial people recognize that in most cases the value of an investment degrades over the time. If you pay $1M for new machinery, it will be worth lot less after five years.

In software we should have similar mentality and we should somehow turn this into numbers. If you don't touch your environment, the value keeps on going down - until it reaches zero. In order to keep the value, you need to constantly work on the environment. Patch operating, upgrade libraries, upgrade frameworks.

Each time you do a quick'n'dirty thing, you essentially increase your liabilities. Refactoring equals to decreasing those liabilities. If you would put numbers for these, you could actually create a balance sheet every year for your software.

</comment><comment><USER4> > Although this backwards incompatible policy causes short term pain for > developers on their platform, Apple made this conscious decision because in > the long-term it leads to an overall healthier ecosystem.

From all evidence I've seen it's more likely they 1) don't care because people are willing to put up with it and 2) don't have the proper type of process/system/codebase/culture to allow such a move (and would rather spend that effort on something else).

One of Microsoft's top 3 selling points in the enterprise is backwards compatibility... They go as far as implementing run-time patches for 20 year old 3rd party DOS binaries that they don't have the source code to when they get crash reports in and it crosses a certain threshold.

> We only have to look at Microsoft's third-party ecosystem to see the > alternative.

A developer that targets Windows breaks compatibility with a previous version of his software, then...? What does that have to do with Windows/Microsoft?

<comment><USER5> The Apple bit isn't _particularly_ true, anyway; look at Carbon. Ten years and counting of supporting ancient apps.

</comment></comment><comment><USER6> When you do a server side upgrade you are essentially doing an upgrade on behalf of every person who uses your product and it's sometimes difficult to roll-back. This is a really good reason to treat server side upgrades differently.

Once you are bit by a bad update you will be very shy about doing it again without a good cause. As an example, we updated to Recent Version - 1 of critical server software and had the thing crashing constantly thereafter. So then we upgraded to Recent Version and had a new bug that was introduced that was causing equal troubles. But now we were stuck and had to wait for next version to fix the bug. Made a really good case for not changing what works.

<comment><AUTHOR> This is just as true for client side upgrades, for example in the App Store. As an app developer you're upgrading every client out there, and it's much harder to revert.

Just as you test on the client side, you should have a staging cycle which tests releases before you deploy them.

<comment><USER7> The advantage you have as a web or app store developer is that if you make a mistake, you can always correct it by shipping a new version. Just imagine the stress that's on the Windows Update or Chrome update teams. If an update to Windows Update itself or to Chrome update itself turns out to be wrong, millions of users could be stuck with a non-upgradeable piece of software and each user would be forced to fix it manually.

</comment></comment></comment><comment><USER8> Ok, I had to laugh at 'spend 20% of your time on upgrading and refactoring'. That will never happen, especially in a small company where engineers are focused on innovation above all costs. At the end of the day, we're so busy pushing out new features that our clients couldn't care less what version of Python we're running on our servers.

</comment><comment><USER9> As a former .NET guy, I have to take issue with the Microsoft devs chiming in about how great the .NET stack is for upgradeability.

Upgrading an ASP.NET web forms app to ASP.NET MVC is painful, and in many cases requires a full scale rewrite due to the high coupling of front and backend code in WebForms apps.

While Microsoft hasn't abandoned Web Forms, it's clearly behind the times in terms of modern web development and Microsoft isn't making much of an effort to bring it up to speed.

Comparing the upgrade of a Rails 2.3 app to 3.0 is a much better story IMO, and a far more realistic upgrade for even the largest apps.

<comment><USER10> You don't "upgrade" from WebForms to MVC - it is a different tool-set. I don't know a lot about the Ruby web world, but it's probably like going from Rails to Sinatra. WebForms still works for the corporate devs, with an IE-only userbase.

</comment></comment><comment><USER11> Apropos little: I kind of love where svbtle (the software/blog network this is on) looks to be going.

<comment><USER12> I'm so used to this being the engine behind, and so unique to, dcurt.is that it actually threw me a little when it wasn't Dustin Curtis's site. I don't know who is/are the developer(s) but my feeling is that it would sit better with a low number of users. Or maybe not, maybe it'll just be like Octopress if it gets opened up.

<comment><USER11> If it goes in the direction of a nerdier Deck advertising network, with a common look/feel, that sounds great to me. More people I think should do those.

</comment></comment></comment><comment><USER13> Best practice is to keep 100% current on security patches (which are often delivered as backports to older/stable versions, e.g. by Debian).

Anything beyond that, and there are multiple schools of thought. One is to keep upgrading bleeding-edge in near realtime -- this keeps you ahead of a lot of known vulnerabilities, gets you access to features, etc., but imposes a cost in constantly fixing bugs.

Another is to do big batch upgrades periodically -- e.g. always updating to Ubuntu Stable within a month or two of release. This breaks more stuff all at once, and has periods of less current software being in production, but is a reasonable compromise.

Another is to deploy things once, get them working, and then leave them in place (with as few upgrades as possible) for as long as possible, then do what is basically a forklift upgrade as required. It has the lowest ongoing cost for maintenance. For something with extensive safety or security critical code which can only be audited and certified at great expense, this is commonly done -- but leads to nice tasty 0-day exploits working well against the most critical systems. It also leads to losing the organizational knowledge, resources, etc. to upgrade.

</comment><comment><USER14> This would be a problem a couple of years ago, but I think it isn't anymore. Any startup can lease it's own webserver(s) (be it VPS, cloud or dedicated) for prices that were unimaginable even 5 years ago.

And best of all, most providers that are appealing to startups (Rackspace, Amazon EC2, Linode...) offer some kind of pay-what-you-use plans, so you can keep costs low at the beginning.

</comment><comment><USER15> Amen. I'm writing a python script that'll install a demo version of our software on a Redhat system, and dealing with an outdated version of python makes things... unpleasant.

</comment><comment><USER16> Updating server software is not rocket science. There are enough good webhosts out there that are doing a great job of keeping their servers up to date. Mind you, they are not the cheapest.

I also like to mention Parallels and their product Plesk that gets updated automatically without any problems; at least on our server.

</comment><comment><USER17> I disagree. If it works once, it works. We're running on Rails 2.3, have been for two years, and have no plans to upgrade. I can't imagine any extra feature we'd need from the framework; if so, we build it ourselves. We've hacked Rails up to fit our needs, and I think that's the way it should be.

<comment><USER18> We thought this was the case as well for some internal apps using an ancient version of Rails. The problems start to arise when you bring in new people to work on improvements to the project after the creators are gone. It is much easier to find someone that knows Rails 3 than to find someone who can dive into Rails 1/2 code. You have to know what the patterns of that "era" were and be aware of bugs and subtle differences that have been ironed out as the project matured.

Imagine trying to find a blog post explaining why your 4 year old version of an image upload gem doesn't work on JRuby. It's no fun :)

<comment><USER19> > Imagine trying to find a blog post explaining why your 4 year old version of > an image upload gem doesn't work on JRuby. It's no fun :)

This really depends if you are running a hobby on a server, or running a business. I update client side apps cause it is exciting and it doesn't matter to me if it breaks. If it does, we cry foul and the developer updates a patch hopefully within a few days or weeks.

On a production environment, this is much different. There's a reason why people say "if it ain't broke, don't try to fix it." A down time of 5 minutes could cost one company thousands while another company millions. If the cash printing machine is down, having a broken image uploader would be the least of their concerns.

</comment></comment></comment><comment><USER20> _We only have to look at Microsoft's third-party ecosystem to see the alternative._

??? What does that mean? It seems rather hand-wavy.

<comment><USER21> Some of his arguments are hand-wavy as well "majority of mature companies in San Francisco..."</comment></comment>


Ask HN: How do you push config to microservices - <AUTHOR> Let's say you have dozens of microservices that live in their own code repositories with config to deploy them to something like AWS. how do you manage boilerplate updates to all of them?<p>Current process is a template repository that gets checked out for new services, however updates to config are made manually to each repo, or copy/pasting boilerplate (which can create havoc if there's an error in the copy/paste) <comment><USER2> You could consider pulling those changes. Each repo should contain just enough config to know how / where to fetch its config + whatever is unique to this repo.

You don't share any details about how you manage configs currently but during your build process you can pull/import/load common configuration from a shared respository whether that's a git repo or etcd cluster or whatever fits your environment.

<comment><AUTHOR> agree that pulling the changes sounds ideal. I guess having the config live in it's own git repo that gets pulled by your build tool during the process might work?</comment></comment>


Why - <AUTHOR> http://question-mark.herokuapp.com/

<comment><USER2> This is as pointless as something can be.

</comment><comment><USER3> Clickbait.</comment>


Palantir worked with Cambridge Analytica on Facebook data, whistleblower alleges - <AUTHOR> https://www.cnbc.com/2018/03/27/palantir-worked-with-cambridge-analytica-on-the-facebook-data-whistleblower.html?__source=twitter%7Cmain <comment><USER2> I am Jill's complete lack of surprise.

Disclaimer: since some folks can't separate explaining something vs agreeing with something, this is just me explaining based on observations and having read Thiels' book Zero to One. I'm still forming an opinion on the matter.

Did anyone not see this coming in one form or another? Thiel openly supported Trump on the grounds that globalization is bad and that a nationalistic president would slow globalization. He believes globalization is bad because it makes us more like China, a country that produces nothing original and instead clones everything innovative from the world. If I do have an opinion on anything, it that Thiel only supported Trump not because he believed in him, but because he knew it would put the brakes on everything he despised.

[https://www.cnbc.com/2017/03/08/thiel-globalization-is- over....](https://www.cnbc.com/2017/03/08/thiel-globalization-is-over.html)</comment>


iPad 2 Order Form is Live - <AUTHOR> http://store.apple.com/us/browse/home/shop_ipad/family/ipad

<comment><AUTHOR> Never had an iPad before...hope it's worth the wait!</comment>


What would you like me to ask David Hansson at 37 Signals? - <AUTHOR>

On Thursday I'm doing a 20 min podcast with DHH.
Do you guys have any burning questions that you would like me to ask him?
Hoping to launch our podcast site next week...once we have some cool interviews. www.beta.dormroomtycoon.com
General feedback and suggestions are welcome also....
Godspeed! <comment><USER2> Two things come to my mind:

1\. What are your thoughts on Unity? (The new Ubuntu desktop) (I know it seems unrelated to business, but it's related to design and aesthetics).

2\. In a startup world filled with products that have no business model other than hoping for an exit, what's your advice to young programmers wanting to start a startup/business?

</comment><comment><USER3> DHH is working on a new javascript framework, one that would create single page js based websites as easily as rails. How is this different from sproutcore? Or from libraries such as jquery, YUI, closure? and a timeline?

</comment><comment><USER4> Is he worried about Asana [http://www.readwriteweb.com/enterprise/2011/04/7-things- to-k...](http://www.readwriteweb.com/enterprise/2011/04/7-things-to-know- about-asana-a.php)

</comment><comment><USER5> Ask him "What is your second-best idea?" Also: "Please share an example of a 'Fortune 5000' business that has not yet been built, but if it were would be a very clever business model."

</comment><comment><USER4> The software industry seems to have a refresh every 5 years or so, will Basecamp ever change to stay fresh with the new competitors coming?

</comment><comment><USER6> If he wasn't in the software business, what venture would he ideally like to run?

</comment><comment><USER7> I would love to know what he thought about racing the 12 hours of Sebring.

<comment><USER8> ^This . Don't know if that would qualify as a "business" topic though, since your podcast site seems to be focusing on business topics.

Maybe a question on the business side of his racing efforts?</comment></comment>


Anyvite takes aim at the Evite juggernaut - <AUTHOR> http://thestandard.com/news/2008/08/06/anyvite-takes-aim-evite-juggernaut <comment><USER2> Based on usability alone, it's not even a competition. The biggest hurdle is getting people to change their ways. Last time I checked more people used yahoo mail or hotmail than gmail. Luckily, anyvite has built in advertising (of the the Anyvite product) any time someone uses it to hold an event.

</comment><comment><USER3> I never use Evite (no one evites me either) so I may not 'get it'. But I don't think anyvite necessarily needs to get people to switch (though maybe declaring war is probably good for PR).

There is potential in the many people who have never used evite. I think anyvite has more of a chance for after work drinks or meals (maybe you need to reserve a table) an other casual & short notice stuff like that. It's probably good timing for a second wave of this kind of thing as mobile internet is getting a critical mass.

</comment><comment><USER4> Evite is a complete pain to use, and confusing to anyone who's never used it before. I think the bar here was set pretty low.

<comment><USER5> The bar for the _product_ is certainly low. The bar for _adoption_ is a much tougher challenge... hopefully Anyvite figures out a way to handle it.

</comment></comment><comment><USER6> I _heart_ anyvite. I use it weekly to organize a poker game.

(If there are any NYC HN people who play 1-2/2-5 NL, give me a holler).</comment>


Intercom's new funding brings valuation to $1.275B - <AUTHOR> https://www.cnbc.com/2018/03/26/intercoms-new-funding-brings-valuation-to-1-point-275-billion.html <comment><AUTHOR> Is this the first unicorn in the 500 Startups portfolio?</comment>


Show HN: Coinfly - A simple invoice service on Stripe (no monthly fees) - <AUTHOR> https://coinfly.com

<comment><USER2> Love this! It's nice and simple.

It's also awesome that it's using on demand pricing. Sometimes I go a month or two without needing to send an invoice so it's great that I don't have to pay for months I don't use this.

</comment><comment><USER3> I'll be trying this out. I've been testing Ballpark by Metalab recently, but I really just need the invoice portion of it. I like that you're only charging $1 per invoice too, I don't send out enough to justify a monthly service.

</comment><comment><USER4> More and more apps built on Laravel 4 already, so good.</comment>


Ask HN: How to more efficiently claim unemployment? - <AUTHOR> Right now I'm claiming unemployment. I'm not really super psyched to get a job. I'm more interested in learning new technologies and exploring other opportunities.
Right now my routine every week is to apply to 5 jobs that are vaguely within my qualifications on a software job site, then claim unemployment on the goverments web site by copying that information over and checking a few radioboxes. Its not very high effort, but its a flow interrupted, and its about 30 minutes to an hour of boring work a week, that would conceivably go on for 16 more weeks.
Is there an easier way to have applied to 2 local companies + 3 other companies every week, and ideally fill out the UI form as well? I'm thinking of something like a very low friction job application system combined with some web automation maybe. <comment><USER2> I'm actually in the exact same position - not super interested in getting a job, very interested in researching and learning, and I've got enough money to be fine for a few years if I really needed to. Obviously I _should_ put forth the effort to build out my resume, apply to some companies that I actually like, and go through the interview process, but I haven't yet. I find it interesting that I'm not the only person in that boat.

As for efficiently certifying UI benefits: I would love to. Here in NY, the labor.gov website is awful and even goes down for hours at a time. If it was any less money I'd be tempted to just ignore unemployment insurance entirely and consider it a trade-off for less time wasted dealing with bureaucracy.

However, according to our claimant handbook[0] we're not able to have someone else fill out the weekly form for us, use an anonymizing internet service, or certify benefits while traveling. In fact, giving someone else your PIN can get you jailed for fraud, so I'm kinda afraid to try automating their system... Given their strictness, I doubt that they would look kindly upon that.

[0]: [https://labor.ny.gov/formsdocs/ui/TC318.3e.pdf](https://labor.ny.gov/formsdocs/ui/TC318.3e.pdf)

<comment><AUTHOR> I'm thinking a system like:

* A very low friction web site has a button to send your resume to X employers fitting UE's condition, and saves that information to a browser plugin.

* The browser plugin fills out the unemployment website when you log into it.

Could be a safe approach, but it is risky territory and its really hard to find out what the limits of the system are. I think making or using a very low friction job application web site would probably be the best gains for time for the lowest legal risk. It, unlike the browser plugin, would probably be easier to solve for a group of people, because theres not the issue of automating different web sites for different states.</comment></comment>


Everything in the Universe Is Made of Math - <AUTHOR> http://discovermagazine.com/2013/dec/13-math-made-flesh

<comment><USER2> I'm always rooting for the anti-establishment math/phys researchers, but this article fails to impress.

Yes, math is everywhere, but Plato said this a long time ago already: [http://en.wikipedia.org/wiki/Theory_of_Forms#Perfection](http://en.wikipedia.org/wiki/Theory_of_Forms#Perfection)

Can anyone explain the new idea here?

</comment><comment><USER3> There's nothing particularly novel or unique about holding the belief that a mathematical model of reality is the same thing as reality. Discussions on HN reveal that many commenters hold this belief, arguing, for example, that a "virtual" universe simulated on a supercomputer would be indistinguishable from a real (or _the_ real) universe.

<comment><AUTHOR> Max Tegmark is largely responsible for popularising the idea.</comment></comment>


Why I'm leaving 18F - <AUTHOR> https://medium.com/@noahkunin/why-im-leaving-18f-48970131d547 <comment><USER2> > Every day he [Trump] remains in office, civil servants have to ask > themselves if political appointees are being given their positions due to > merit, or to personal loyalty to Trump, or someone else in the > Administration.

Sounds like it was time for the author to move on and I wish him well, but his impact was highest inside the tent. With patience, flexibility and choosing his battles wisely he might have had some influence within his sphere of responsibilities.

The author conflates norms for appearances. For good or bad Trump largely dispenses with appearances and practices his political maneuverings in the open, appearances be damned. But the practices are the same either way.

I've interviewed for an executive branch position where having voted years prior for the opposite party disqualified me. I've worked in a state campaign where my relatives, having donated to the opposite party, placed me under suspicion. Patronage and loyalty testing are the _OLDEST_ of political practices. None of this is new under Trump, and none of it ever changes except in times of indisputable and existential national crisis.

Existential crisis is pretty much upon us. Much blame is deserved across the political spectrum for how we've arrived here.

<comment><USER3> "This stuff happened before at a smaller scale by everyone," is a terrifying argument _of_ normalization. It was wrong then. The norms were to crack down on that sort of thing when it happened. Now it's an excuse because the past wasn't perfect that we should normalize the worst excesses of wrongness as the new right. That's frightening.

<comment><USER4> I think you've read something into the GP that wasn't there. I don't see them justifying or excusing bad practices anywhere in the post. Merely stating that they occurred (which is true).

> _The norms were to crack down on that sort of thing when it happened_

This what the GP is really getting at. This was never cracked down on in the past (I have no clue where you'd get the idea from that it was) because it wasn't done in the open as it is now. Now that it's blatant, we may finally have an opportunity to fight it.

<comment><USER5> > This what the GP is really getting at. This was never cracked down on in the > past (I have no clue where you'd get the idea from that it was) because it > wasn't done in the open as it is now.

It wasn't done in the open because all kinds of structures, both formal and informal, were erected to crack down on it after the _last_ time it was done so flagrantly in the open; OTOH, those have been systematically eroded over the last several decades so that with the political branches sand judiciary all in the hands of the same faction, they no longer function to restrain it.

</comment></comment></comment></comment><comment><USER6> I don't really find this post to be rational. 18F started out as a part of the executive office of the president. Their whole recruiting pitch revolved around the ego boost of the proximity to power. It was later moved under the umbrella of the GSA.

Nothing described in this blog post with respect to 18F is exceptional or abnormal. The heads of major agencies and their sub components have always been political appointees. Government agencies reorganize internally constantly. 18F started out life being run by a political appointee and has previously been reorganized from the EOP to the GSA. The only difference now is that the OP doesn't care for the politics of the current administration.

<comment><USER7> I think you might be confusing the U.S. Digital Service, which started in the executive office of the president and is still there, and 18F, which started in GSA and is still there.

<comment><USER6> I should have been more exact. The original 18F team was made up largely of former Presidential Innovation Fellows a program created by the EOP. The Presidential Innovation Fellows program predated 18F and was moved under the purview of 18F when it was created. So you are right wasn't part of the EOP but everything else still stands. They were created by the head of the GSA, a political appointee and a program created by the EOP was reorganized into them at their creation.

</comment></comment></comment><comment><USER8> Reminds me a bit of this earlier piece on Lawfare: [https://www.lawfareblog.com/your-city-or-your-soul-moral- com...](https://www.lawfareblog.com/your-city-or-your-soul-moral-compromise- and-government-service)

</comment><comment><USER9> I don't mean to imply that the actions of the Trump administration are healthy or appropriate. But having just read "Dereliction of Duty" [1] about the Kennedy and Johnson administration and how the Vietnam War was managed in its early days, I think it's clear that the kind of behavior here, especially around valuing personal loyalty over competence or being given accurate information is not a new phenomenon.

The fallout of Watergate, especially the fact that the executive no longer routinely records conversations, mean that we'll never have a good idea of normal/not-normal in this context ever again the way that we have it for the Kennedy and Johnson administrations. So I can't say whether subsequent presidents have made similar decisions, but the "personal loyalty" thing is very definitely not a new thing.

Note that this isolation from reality had large-scale disastrous consequences at that time, so this is not to say that we should become complacent about it. But in itself, I'm finding the "not normal" critique to be a bit shallow; a sort of tu quoque that substitutes for actually criticizing the concrete actions of the administration.

[1] [https://www.amazon.com/dp/B004HW7834](https://www.amazon.com/dp/B004HW7834) \-- written by H. R. McMaster, our current National Security Adviser, who I sincerely hope will hold to the standards that he advocates in that volume.

<comment><USER3> The "norm" then was to crack down on the wrong when it came to light. Watergate's actions were done in secret and the heroes of the story were journalists investigating the wrongs and trying to correct them.

Just because the past wasn't perfect doesn't mean we shouldn't stop striving for perfection. Watergate having happened doesn't give the administration a blank check to carry out Watergate-level actions in public and treat them as if they were normal and as if they were right.

<comment><USER9> Watergate was under Nixon, not Johnson or Kennedy -- I was merely pointing out that the side effect of Watergate was that presidents no longer recorded their conversations. This prevents us, for the sake of determining what is "normal", from having a record of what was actually being said by the president and his advisors while these terrible decisions were being made.

Watergate was a criminal act. The acts of Kennedy and Johnson were not criminal, just irresponsible. In particular, cronyism and requiring personal loyalty are not "not normal" as alleged, and the "not normal" argument in general wears a bit thin and lacks any historical perspective.

<comment><USER3> The article here points out that yes, the "normal" in US politics has since about the founding of the country been that the only fealty oath used by the federal government was one to the Constitution and the People. Cronyism and personal loyalty were not criminal, but were considered unethical and when such things come to light, it was the job of a free press and other parts of the government to fix them and make things better. It was never openly "normal" in any school of American government history to accept cronyism or personal loyalty. Sure it happened, but the goal was to reduce and/or eliminate it; that was the presumed "norm".

</comment></comment></comment></comment><comment><USER10> In addition to the obvious political angle, it's nice to see an engineer talking about their duty to the populace. Software engineers hand waive this off because we generally aren't building things that can kill people. We are however building things that have tremendous impact on people's lives, and many in our profession do not seem to take that seriously.

</comment><comment><USER11> Important reading. More people are going to have to make hard choices like this as the months unfold, I'd imagine.

</comment><comment><USER12> Here is the part that's news: "18F (and the larger service we created for it and its sibling organizations, the Technology Transformation Service), is being reorganized via administrative order into the General Services Administration's (GSA) Federal Acquisition Service. [...]

"We were subsequently told that the new Commissioner of the Federal Acquisition Service would [...] immediately become a political position, with a person appointed directly by the White House."

(The rest is standard anti-Trump rhetoric.)

<comment><USER13> > (The rest is standard anti-Trump rhetoric.)

Everybody's saying it so it must be unimportant! It's not new so who cares!

<comment><USER14> Yeah, people think they're really fucking cool with that sentiment sometimes. "Oh wow, news flash, VCs are sexist". Super unhelpful attitude.

<comment><USER15> Is this post satire?</comment></comment></comment></comment>


Four rules to make Star Wars great again - <AUTHOR> http://kottke.org/13/09/four-rules-to-make-star-wars-great-again <comment><USER2> This is awesome :)

I like the frontier stuff most of all. Still, I'm not sold on the "old" part. That's only true for the rebels, and anly for episode >4\. In the previous one, it should be newer. Obi Wan Kenobi WAS young, in a certain moment in time, you have to admit...</comment>


Static Analysis Fatigue - <AUTHOR> http://blog.regehr.org/archives/259

<comment><USER2> I think "actionable" is the keyword here. Dumping the error messages straight from the tool into a bug report does not tell the recipient

(a) how many false positives there are - either code paths that don't occur in the wild or undefined behaviours that actually yield the same result in all sensible implementations (as the a+b-c versus a+(b-c) case), or what possible/likely consequences of such implementation-dependent behaviour would be.

(b) how he/she can reproduce the bug to see if it disappeared (hence the PHP guy's request about the exact test cases these errors occur in)

It's also not quite helpful if people cannot run the debugging tool themselves. This is pretty independent of whether the tool uses static analysis, or runtime debugging, or a mixture of both.

</comment><comment><USER3> Backstory to this: there's a bunch of commercial providers of code security/reliability scanners (Fortify, Coverity, Ounce, Klocwork; surely there are others) all of whom simultaneously got the great idea of running their stuff on big open source projects (as a "donation") and then press releasing the findings.

<comment><USER4> Yes. These tools are great if you can include them in your nightly build, and if they're accurate enough you can insist on 100% clean runs every night. But a big dump of cryptic errors, many of false positives, from a commercial vendor with a proprietary tool? If you care about security, you've _got_ to act on it. But I understand why volunteer maintainers get pretty grumpy after the first half-dozen false positives, or if the tool seems to be half-baked.

<comment><USER5> There is another problem with this type of tools, you can read about it here:

<http://blog.regehr.org/archives/226>

most of what it's found while still a bug may never lead to erratic behaviour, it's hard to estimate the severity of each bug and it's a lot of work to wade through all of them.</comment></comment></comment>


Electricity consumption of Bitcoin: a market-based and technical analysis - <AUTHOR> http://blog.zorinaq.com/bitcoin-electricity-consumption/ <comment><USER2> A growing trend is to mine Bitcoin in Venezuela, where the electricity is hugely subsidized, mining can pay better than something like being a doctor, and you can get food sent in from Miami (since your income is in a widely accepted currency.)

Good Econtalk on the subject: [http://www.econtalk.org/archives/2017/02/jim_epstein_on.html](http://www.econtalk.org/archives/2017/02/jim_epstein_on.html)

</comment><comment><USER3> In other words, the Bitcoin network consumes about 5-6 orders of magnitude more electricity than would be required to maintain a similarly-sized ledger using more traditional database techniques.

Yes, the feature set is a bit different, but it's difficult to see how Bitcoin can remain competitive in the long run. I guess it can help push down overheads elsewhere in the financial system, so at least that's a good thing. And it's always been a good educational experience.

<comment><USER4> The point of Bitcoin is to consume as much electricity, roughly, as a block is worth. Consuming this electricity, and using it to calculate a proof of the consumed electricity, means that the blockchain becomes immutable: no one can change the past, because it would require re-doing the proof-of-work.

So, out of this -- seemingly meaningless -- activity of burning off energy, arises the trustless property of the Bitcoin blockchain: with digital currencies that use proof-of-stake, or an SQL backend, every participant could -- theoretically -- have mutually agreed on assigning themselves 100x as many currency units, right before you enter and buy $1000 worth. There's no way to prove that this didn't happen, as it takes little effort to change history. This is unacceptable for a digital currency, hence the need for proof-of-work, and Bitcoin.

<comment><USER3> It's easy to change history with a plain SQL backend. But in any approach that stores the ledger in anything that boils down to a publicly distributed Merkle DAG, changing history or other manipulation like generating assets from nothing is impossible to do in secret.

The only potential issue is double-spending, or to be more precise, invalidating a transaction after the fact by pretending that a different, conflicting one, came first. This problem could be solved much more cheaply than in Bitcoin by using signatures by a trusted (e.g. elected) well-known council.

The only problem with that approach is how to bootstrap the value of such an alternative currency. Bitcoin somehow achieved that by appealing to a mixture of cypherpunk and libertarian ideology, and from there it developed to the current status which is an entirely circular origin to the value. I don't know what the alternatives for bootstrapping are. Fiat currencies can bootstrap via taxation, but that's not really an option here. Perhaps something like getting Valve to use such a system for their card trading :)

<comment><USER4> > The only problem with that approach is how to bootstrap the value of such an > alternative currency

The problem of "bootstrapping the value" of a centralized, digital currency is that no one wants it, because of the reason I mentioned (too easy to change history). Working hard in order to earn an entry in some database, that can be deleted in a second, makes little sense for people.

Bitcoin had no bootstrapping problem because it can be used tustlessly (deleting past transactions is simply not possible), while your solution is just another type of credit. Why would I ever, voluntarily, start using your credit as money? It makes no sense from my perspective; hence the "bootstrapping problem".

In short: reducing the energy consumption of Bitcoin while reducing security is easy (use credit). It's keeping the trustless property while reducing energy usage that's the challenge.

<comment><USER3> I'm not sure what you mean by _centralized, digital currency_ , but it's probably not what I was talking about, which involves a _publicly distributed Merkle DAG_.

Also, it's disingenious to pretend that Bitcoin had no bootstrapping problem. Bitcoin existed for a long time without significant value, and it seems stunts like spending what would now be millions of dollars for pizza were necessary pieces of solving the bootstrapping puzzle.

<comment><USER4> I'm referring to your solution to the double-spend problem, which is the problem Bitcoin solves in a trustless manner.

> This problem could be solved much more cheaply than in Bitcoin by using > signatures by a trusted (e.g. elected) well-known council.

This is a centralized solution, where a group of -- albeit elected -- officials have complete control over the history of all balances. I'm arguing that no one is interested in such a system. No one wants democratic money, when it comes down it, is what I'm arguing. They want trustless money.

I'm also arguing that Bitcoin has monetary value in and of itself -- because it has use value -- and that its dollar price is a symptom of that, not the other way around. Even with zero dollars bidding on bitcoins, Bitcoin can be used for spam prevention -- out of which it was derived in the first place (Hashcash).

</comment></comment></comment></comment></comment></comment><comment><USER5> In the future bitcoin[1] mining is banned on inhabited planets and instead done on Dyson spheres.

[1] It's the future, so neither bitcoin nor internet are capitalized.

<comment><USER6> if this happens, bitcoin would become valueless. The value of bitcoin comes from the fact that you can't just pump them out, the energy requirements required to solve the calculations required for mining are one of the limits to bitcoin production. Free energy like feasible solar or dyson spears would just be a license to print free digital currency making it worthless.

<comment><USER7> The network recalculates payoffs based on the hashrate. If electricity becomes cheaper, hashrate goes up, and the payoff per hash goes down.

</comment></comment></comment><comment><USER8> I think a rough estimate of the cost of 500MWh/year is $500 million per year. That doesn't include cooling, hardware, real-estate, staff and other operating expenses. I guess the majority of this cost is ultimately paid for by speculators who buy Bitcoins off of the miners.

<comment><USER9> $500 million per year is roughly what I get, too, but 500MWh/year is very different from 500MW, which is what I think you meant to write since the OP expresses its conclusion in MW.

</comment></comment><comment><USER10> If you accept that (1) there are economies of scale in Bitcoin mining and (2) miners are rational and will only mine when it is profitable, then doesn't this suggest that large amounts of mining power should become concentrated in the hands of just a few major miners? Doesn't that seriously undermine Bitcoin's validity?

<comment><USER10> This article seems to support my suggestion.

[https://www.cryptocoinsnews.com/declining-profitability- for-...](https://www.cryptocoinsnews.com/declining-profitability-for-new- miners-threatens-bitcoin-decentralization/)

Quoting the conclusion of the referenced paper:

"Each future halving of the Bitcoin block reward will narrow the range of profitable entry for new Bitcoin miners considerably. The stronger relative position of incumbents compared to that of new entrants supports further consolidation of Bitcoin mining. Consequently, the distributed Bitcoin ledger, the blockchain, may become more vulnerable to attack, and its trustless nature may ultimately even be destroyed."

<comment><USER11> " Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free" \- btc whitepaper

Transaction fees will take over mined bitcoins once there is non left to mine.

<comment><USER10> Okay but that does not solve the problem I am concerned about. That doesn't ensure a _diverse_ mining pool. Already it doesn't make sense for me to mine Bitcoin (I don't have access to these ASICs). I think that economic forces will tend to concentrate mining power and that's a problem.

</comment></comment></comment></comment><comment><USER12> At one ton of CO2 per megawatt hour, we could be looking at 2 million tons CO2 a year. [https://www.eia.gov/tools/faqs/faq.cfm?id=74&t=11](https://www.eia.gov/tools/faqs/faq.cfm?id=74&t=11)

100 gallons of gasoline also creates a ton of CO2 for context.

<comment><USER13> > 100 gallons of gasoline also creates a ton of CO2 for context.

I thought I understood the Law of Conservation of Mass, but I guess I do not. If 100 gallons of gasoline has a mass of ~283.49 kg [0], how is a ton of carbon dioxide created from this?

[0] Maybe I'm wrong to use the first site that came up, but I used [http://www.aqua-calc.com/calculate/volume-to- weight/substanc...](http://www.aqua-calc.com/calculate/volume-to- weight/substance/gasoline)

<comment><USER14> Carbon atoms from the gasoline each combine with two oxygen atoms from the air to produce a carbon dioxide molecule, meaning the bulk of the mass of the resulting co2 actually comes from the atmosphere.

</comment></comment></comment><comment><USER15> They make the assumption that unprofitable hardware has been retired. But this assumes that the person profiting from the mining is also paying for the electricity.

<comment><USER16> > But this assumes that the person profiting from the mining is also paying > for the electricity.

Otherwise it doesn't make sense. You cannot steal electricity forever.

<comment><USER17> You can hack into new aws accounts forever.

<comment><USER18> AWS is highly inefficient to mine Bitcoins. A 4-GPU EC2 instance will mine less than $0.50 per year(!)

Realistically the proportion of miners who steal power is likely very small, as in one or two percentage points.</comment></comment></comment></comment>


The Town That Creep Built - <AUTHOR> http://bldgblog.blogspot.com/2015/04/the-town-that-creep-built.html

<comment><USER2> How do property line disputes get resolved in an environment like this? Imagine you and your neighbor are engaged in a petty feud over the location of a block wall. Does your property change shape with the Earth? Or do fixed objects drift into your property, and now that wall belongs to you?

EDIT: This kind of answers, but it's not entirely clear: [http://www.sfgate.com/bayarea/article/When-property-lines- ru...](http://www.sfgate.com/bayarea/article/When-property-lines-run-through- the-front-door-2662450.php)

<comment><USER3> I'm working with a simplified model - visualize a row of 10 houses, each on a square plot. There's a street running along the row of houses, and a street at each end.

Now, the land slides 1/2 plot to the right. To simplify this model, the slide happens overnight.

This means that each house slides right 1/2 plot. All of the cars slide 1/2 plot to the right. The yards and all the flowers slide 1/2 plot to the right.

And the road slides 1/2 plot to the right.

So this means that one of these residents now owns 1/2 plot of public roadway. Are they allowed to toll drivers for using their roadway?

The city (or county or state) now owns 1/2 plot of yard (and 1/2 of a house), which isn't quite as useful to them as the 1/2 plot of roadway they had before the shift.

Whichever governmental body that has authority could theoretically solve this by shifting all property lines to the right by 1/2 plot. This would line up the spots on the Earth's spherical surface (the land estate) with the objects held there by gravity and other forces (buildings and possessions).

\---

Of course, the complicating force here is Human Boredom; since these changes happen over decades instead of a night, most people are not content to have the problem solved logically, as most people see problems as tools they can use as a reason to talk to other people.

<comment><USER4> But what happens if due to sliding, one house moves over 1/2 plot but after compression, the next property over moves over 1/4\. Now a mathematical and spacial change based purely off of property lines is going to misrepresent the actual change, while an adjustment based off of sliding objects may strip someone of 1/4 a plot of land. It's not a simple "just move the plot" solution unfortunately.

<comment><USER3> Thanks for clarifying some of the details that complicate my simple model.

I feel like Eminent Domain might be one recourse - simply pay the land owner for the land that was lost. Though the land prices in California are so high as to make this prohibitively expensive.

Another solution could be to take that 1/2 plot of land the city got, and give 1/4 of that to the squeezed landowner. But that solution wouldn't scale well - I foresee a nightmare scenario where hundreds of people are trying to sell their fractional ownership of a sandlot, except for one disgruntled group member.

<comment><USER2> I think the answer to this scenario is simpler. Tell them, "Sorry, God just screwed you out of 1/4 of your land. Man that must suck. At least your property taxes will be reduced!"

<comment><USER3> Yes, but which god? Ishtar? Most of them aren't _that_ fickle.

</comment></comment></comment></comment></comment></comment><comment><USER5> This is an interesting photo:

[http://4.bp.blogspot.com/-NqtW3VGYkuw/VGTYSD72MLI/AAAAAAAA_z...](http://4.bp.blogspot.com/-NqtW3VGYkuw/VGTYSD72MLI/AAAAAAAA_zw/JEhpH7_OUt0/s1600/7-HollisterDrainWEB.jpg)

It immediately makes you wonder what happens "underground"..

<comment><USER6> No need to wonder, sewer lines that cross a fault line simply break. During my time here in the SF Bay Area I know of at least three water line incidents which were directly caused by water mains that were damaged by earth movement. One in San Francisco in the late 90's created a huge sink hole as the water washed out the under part of a street, one in Berkeley where the REI store flooded, and one in Fremont which may have been a combination of fault motion and land settling.

<comment><USER7> Yes but they know the fault is exactly there and moving at a constant rate, it's possible they could plan for it.

</comment></comment></comment><comment><USER8> That's really fascinating. I wonder how much a typical home can torque before it becomes unsafe and how would you go about fixing it? I can't imagine it's an easy repair. Can the house be lifted (as if it was going to be moved) and the foundation re-done or does it pretty much need to be demolished?

<comment><USER9> If the house is a frame house on pilings, it's pretty easy to fix that way; if it's a monolithic slab, block home, you're screwed. So it depends heavily on the foundation and construction style.

<comment><USER10> And I imagine if, at this point, you're not constructing houses with this activity in mind, there's no one to blame but yourself. Sure, it sucks for older houses, but if newer houses are being built more commonly now as the article says, the problem should go away over time.

</comment></comment></comment><comment><USER11> I can't help but look at the roads and sidewalks and think there's a solution that could be implemented there. I'm no engineer, but I expect that you could install something along the fault line that allows the road to slide apart without disruption. It seems like a waste to just keep repaving the same spot over and over, just for it to crack again.

Maybe tear up a couple feet of pavement and put in two metal grates that can slide past each other. That should at least buy you a decent amount of time, until the road is so warped that the lanes don't line up.

<comment><USER12> The Alyeska pipeline in Alaska is built on rails just like this over the parts near the Denali Fault.

[http://earthquake.usgs.gov/earthquakes/eqarchives/year/2002/...](http://earthquake.usgs.gov/earthquakes/eqarchives/year/2002/TAPSatDenaliFault.gif)

<comment><USER13> I stared at that for far too long, waiting for the animation to start.

</comment></comment></comment><comment><USER14> So what happens to the underground infrastructure? Water, sewage, storm- drains, gas?

</comment><comment><USER15> Do homeowner's insurance policies out in California cover ground movement?

<comment><USER16> As a surprising aside, I found that homeowner's insurance in Hawaii covers "destruction of house due to lava" but not "destruction of the entire area around house, but not house due to lava".

There are people who have no roads, water, sewer or electric because their house was turned into an island by lava flows - and they have no recourse to do anything with their property (that they sometimes cannot even get to any more).

<comment><USER2> If the lava flow is active, built a drawbridge and have the best moat ever!

<comment><USER17> underfloor heating included if you're lucky, though that may be of little appeal given the climate.

</comment></comment></comment></comment><comment><USER6> One of my favorite nearby parks: [http://www.yelp.com/biz/los-trancos-open- space-preserve-palo...](http://www.yelp.com/biz/los-trancos-open-space- preserve-palo-alto) has the San Andreas fault going right through it. You can see where the fence line has been deformed by creep.

On the plus side if it deforms you don't get a lot of energy buildup.

</comment><comment><USER18> reminded about what happens to buildings built on permafrost in Siberia on shoddy quality foundations (i.e. for example the correct foundation should go well deeper than summer thaw depth)</comment>


Ask HN: How should one respond if a sales call turns into an investment call? - <AUTHOR> <comment><AUTHOR> Who doesn't like a strategic investment from a customer? I was pitching to a client and he offered that his company would like to explore investing rather. Now he wanted to know the details of the company and I told him some figures of the company. Have I jeopardised my chances of even turning him into a customer?

<comment><USER2> Would have been nice to qualify the interest more before sharing the company details. Did you do that?

(If you did not) Now you operate at a very significant disadvantage. They have a lot more information about you than you probably do about them. Generally, but not always, control over where this all goes is more in their hand than yours.

Had that discussion been better qualified, you probably would know more about them becoming a customer, for one, and would have gotten value in return for value given. And control would be better managed by you.

Why do they want to invest? How long have they been looking for an opportunity like your firm?

Why?

And with that, for what returns and how do those align with both your business and theirs?

<comment><AUTHOR> Oh yes, I did qualify him for investments and thankfully, I did get answers to all the questions above. I was directly talking to the founder and had researched about his story before getting on the call. He sold his previous venture and is also a partner at a fund in US. I also understood his interest in our company and what are other similar companies he has considered? We also talked about the competition in US and global, both. It flowed like a conversation and I am glad that he was upfront about investing rather than using tricks to fetch information.

I was worried because I just went with the flow and had afterthoughts if I should ever change the context of a call! I am very wary of investors who do not have any entrepreneurial experience. Most of these investors, at least in India, have a very cosmetic entrepreneurial experience?

<comment><USER2> Seems to me you could wrap all this up into a summary call.

Next steps along the investment track.

Does a sale make sense given investment potential and need / timeline previously identified, if it was identified?

(Was it?)

In the spirit of working more closely, are they aware of any prospects? Perhaps jointly approaching them, or some other arrangement makes sense?

Continuing to grow makes all the sense in the world, right? Taking it that way is hard to find fault with.

You are likely to get the info and maybe position in the conversation you need. At the least, next steps will become more clear.</comment></comment></comment></comment>


The freedom to eat pizza - <AUTHOR> https://raganwald.posterous.com/the-freedom-to-eat-pizza <comment><USER2> I was almost completely buying into the theme park and pizza concession analogy. But then I thought of the one exception. You're allowed to buy Amazon pizza outside of the park and bring it in for free, but only if Amazon has agreed to set up a pizza shop inside the park as well.

And I think that's the key point of contention. I don't mind Apple taking a 30% cut of anything I sell from within my app. And I don't mind when they make an editorial decision and make me remove offensive or inappropriate functionality from my app. But compelling me to add or implement functionality in my app or be rejected, that's contentious for me.

<comment><USER2> I'm _really_ curious what the status would be of third-party content applications. Let's say that Amazon exposed reading functionality in a Kindle Web API but not purchasing functionality. So I implement an iOS application called kReader which can read Kindle books.

I wonder where I'd fall in Apple's rule restrictions then, since I'm not offering anything for sale either in-app or out-of-app.

</comment></comment><comment><USER3> There's a lot more lock-in with a phone than there is with a theme park. If I go to Disneyland and I don't like any of the restaurants there (which is the case), I can just eat at the Denny's across the street. A more apropos comparison would be North Korea.

Again, if Apple allowed apps from outside the App Store on iOS devices, none of this would be that much of a problem. You could still sell to these people, but you just wouldn't be going through Apple to do it. Apple is essentially abusing its monopoly position in the mobile app market combined with its control of the phone itself to strong-arm money out of people.

Just so people understand my position: I've used Apple products almost exclusively since 1984. My primary computer is a MacBook Pro, and my phone is an iPhone 3GS. I'm not the sort of person who loves hating on Apple. But this really is nothing more than Apple being _exactly_ the sort of bully Microsoft was in the '90s, and I don't like it.

<comment><AUTHOR> I never said you should like it. I hope that my post conveys the idea that I don't like Apple or Amazon's approach to locking people into content like books.

</comment></comment><comment><USER4> I think it is a great analogy because it also points out the value of the "theme park" to the consumer: they feel safe with the vendors within it. In a lot of ways, that 30% is paying not just for Apple's e-commerce, but Apple's stamp of approval.

My bet: Amazon and Apple will spend a lot of time posturing and then will suddenly go quiet. Amazon (and the other "big names", who don't benefit from Apple's name) will end up paying a smaller fee. Everyone else will pay their 30%.

Also, you have to remember that the face value of "Apple$" is not 1:1. Around here (Australia) you can generally get iTunes cards at "20% off", which makes them a better mechanism for the consumer than paying by credit card, but which must be cutting into Apple's 30%.

</comment><comment><USER5> This seems a bit condescending.

(most) Everyone is aware of the situation and understands the risks -- it does not mean they cannot complain about the margin cut killing their business or the requirement to enforce the margin cut for content both in and out of the app store (even when said content is not linked to by the app).

I dont see how giving away things for free is relevant.

<comment><AUTHOR> Absolutely complain, you always have that right. I am just saying that I consider most of the barking about this to be the Lion arguing with the Cheetah about how to divvy up the Antelope's flesh.

</comment></comment><comment><USER6> Don't restaurants inside theme parks charge _more_ for their food than outside? Maybe I'm wrong and have been visiting the wrong theme parks but that has been my experience.

They can get away with it because once you're inside the theme park, it's convenient to buy your food in there, instead of hauling it in from outside.</comment>


Ask HN: If everyone was as smart as you, what would the world look like? - <AUTHOR> If everyone in the world was as intelligent as you — however you define intelligence but mostly smarts here - not compassion, emotional IQ, empathy or anything like that. Assume that those sorts of things continue to exist in the same distribution (or explain how they are connected intrinsically to intelligence). How do you think the world would be different and what would the probabilities of it being better or worse? Feel free to extrapolate on macro or micro levels -- from socioeconomic systems to romantic relationships. <comment><USER2> The population would be far lower -- because apparently you either get smarts or you get laid.

And we'd all be living in grass huts on the beach. Eating whatever fruits were reasonably easy to acquire.

Not because this is an ideal situation. It's not. But rather, because we're not getting laid anyway so we all lack motivation to do anything to impress MOTAS.</comment>


Music education should be about music production, not playing classical music - <AUTHOR> https://theconversation.com/why-music-lessons-need-to-keep-up-with-the-times-58268 <comment><USER2> Classical music is the foundation for understanding music production</comment>


New XPS 17 Laptop - <AUTHOR> https://www.dell.com/en-ca/shop/dell-laptops/new-xps-17-laptop/spd/xps-17-9700-laptop <comment><USER2> Hard pass on Dell, get you a Pixelbook Go instead. Much better Dev experience than vanilla Linux.

(See my other PBG comments over the last two days for more reasons why)</comment>


Nuke Lamp - <AUTHOR> http://www.shapeways.com/model/287682/

<comment><USER2> I wonder how it looks in a more realistic environment (i.e. when the background isn't pitch black). Even after quite a bit of Googling I can't turn up any other photos of it

It's a shame it costs $1300.

<comment><USER3> Maybe it's much cheaper to create your own 3D model of a nuke and let it print in 3D (or print it yourself if you happen to own a 3D printer).

Or print your own brain as lamp: [http://www.lervik.se/index.asp?func=show&cat=Collection&...](http://www.lervik.se/index.asp?func=show&cat=Collection&m=l&id=216)</comment></comment>