Chromium unconditionally downloads binary blob - <AUTHOR> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909 <comment><USER2> The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a.

This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it might instead accept instructions to transmit audio from particular parties that Google wants to spy on.

I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed.

This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android, twice: once with the "Play Service Framework", which is a collection of APIs added to Android but theoretically independent of it, and again with Google Glass, which ran an entirely closed-source fork. In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.

<comment><USER3> _> I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed._

That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.

If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.

edit: s/Google Chrome/Chromium/g

 _> This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android_

Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.

 _> In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google._

Did you do a write up of this study? I'd be interested to read it :)

<comment><USER4> > Android is Google's project to begin with

It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]

> and the closed components which are part of the Play Service Framework _have > been a part of Android since it 's initial release._

No, Google Play Services was first released in 2012, whereas Google's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning.

[1] [https://en.wikipedia.org/wiki/Android_(operating_system)#His...](https://en.wikipedia.org/wiki/Android_\(operating_system\)#History)

[2] [http://android-developers.blogspot.com/2008/09/announcing- an...](http://android-developers.blogspot.com/2008/09/announcing- android-10-sdk-release-1.html)

<comment><USER3> _> It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]_

Fair point, but AFAIK Android was never released as an open source project until it was Google owned.

 _No, Google Play Services was first released in 2012, whereas Google 's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning._

You were emphasising the wrong part of my sentence. Many proprietary components that are now part of Google Play Services have existed seperately for longer than the "Play" brand had: [https://en.wikipedia.org/wiki/Google_Mobile_Services](https://en.wikipedia.org/wiki/Google_Mobile_Services)

<comment><USER4> > Fair point, but AFAIK Android was never released as an open source project > until it was Google owned.

Since we're both being pedantic here, I never said that it was. :) I believe the GP did though (the person you were initially replying to, that is).

> Many proprietary components that are now part of Google Play Services have > existed seperately for longer than the "Play" brand had

You're right, and that's one of the things that bothers me about Android's reputation for being an "open" or "open source friendly" OS. Yes, AOSP is open source software (if you leave out the binary blobs necessary for the radios and GPU to work), but even plain vanilla Android as shipped by Google is far from open source. Google has steadily been moving towards a closed/locked down model in many of their projects.

</comment></comment></comment></comment></comment><comment><USER5> So, if the article was titled "Chromium downloads and activates closed-source eavesdropping software on all its devices, bypassing any OS alerts", would that be too wordy? It's meant to be a little tongue-in-cheek, admittedly, but it seems to me that's exactly what they did.

Isn't Chromium behind the enterprise chromebox/chromebook stuff too? And does this mean that Chrome itself may, or has already, install eavesdropping software and activate it without my knowledge?

Edit: I see from a sibling comment that OS X has this eavesdropping software installed, so that leads me to believe that everyone running chromium devices will have this activated, and that it's going to be part of Chrome soon, if it isn't already.

I know it's hyperbole to call it "eavesdropping software", but I also know how many people here were unsettled by "OK Google" and "Alexa!" (Amazon Echo), and I really do want to understand how folks here feel about the intrusion.

<comment><USER6> Chrome is eavesdropping software. Claiming it was installed without authorization does not cut it.

By its turn, Chromium's only selling point was that it was free of the eavesdropping features.

</comment></comment><comment><USER7> A bit surprised that there is no security CVE report attached. Debian policy is that binaries are vetted by a debian developer, sorted into Main, Contrib and Non-free, cryptographically signed and later verified by the client package system. The bug could allow arbitrary code to be installed and run without any of the above process if someone MitM the connection between the binary file and the client.

<comment><USER8> Isn't the blob downloaded from Google's servers over a HSTS and cert-pinned TLS connection?[0] If someone has MitM'd Google, it's gonna be a bad day for a _lot_ of people.

From my POV, the thing that's _actually_ bothersome about this issue is that a closed-source blob is automatically inserted into a project that I -and others- had understood to be completely open-source.

The fact that the Chromium Google Hotword code was later made opt-out -rather than opt-in- through a build-time configuration option is similarly troubling.

[0] IIRC, Chromium _does_ support enterprise TLS snooping/interception devices, but those certs have to be loaded into Chromium before such devices will work.

<comment><USER7> Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection. Secret downloads has the problem to display certification errors and similar things to the users, so they would likely have to reimplemented quite a few code paths to make that work properly. https and tls is also not mentioned in either bug threads, which is a worrying sign.

If it uses TLS, then the bug is less exploitable but does still violate security policy of the vetting process, signed code and license classification (closed-source blob). At minimum, it leaves anyone vulnerable to arbitrary code injection from Google.

<comment><USER9> > Since it doesn't use the normal ways to download extension, I would assume > it does not use TLS connection

If this was some random enterprise Java app, yes, that would be a reasonable assumption but you're talking about one of the most heavily audited codebases in existence, which has one of the best security teams in the world working on making TLS stronger and aggressively pinning certificates. Their track record would merit actually looking at the source rather than simply speculating.

</comment></comment></comment></comment><comment><USER10> Note that although this bug report was forcibly closed, the fix is "This change adds an "enable_hotwording" build flag that is _enabled by default_ , but can be disabled at compile time."

Consider what this backdoor does. It listens to any conversation in the vicinity of the phone and reports it to a remote site. You can't see its keyword list. You can't tell when it's transmitting to the mothership.

Has anyone filed a US-CERT report with Homeland Security on this?

<comment><USER11> _Has anyone filed a US-CERT report with Homeland Security on this?_

"Yeah, we know. It's ours. Don't worry about it. Go about your business. Pick up that can, while you're at it."

</comment></comment><comment><USER12> From the comments on the debian bug, this appears to have been fixed in Chromium. [https://code.google.com/p/chromium/issues/detail?id=491435](https://code.google.com/p/chromium/issues/detail?id=491435)

<comment><USER13> Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.

<comment><USER14> While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.

<comment><USER15> Chrome's Flash Player uses PPAPI (Pepper), not NaCl. Pepper Flash is still running Adobe's native code, not NaCl code.

<comment><USER16> So it's using the NaCl sandbox and interface without the bytecode parts?

<comment><USER15> As I understand it, NaCl is a Pepper plugin, but Pepper does not rely on NaCl. Other Pepper plugins are not necessarily using NaCl.

[https://code.google.com/p/nativeclient/wiki/Pepper](https://code.google.com/p/nativeclient/wiki/Pepper)

</comment></comment></comment></comment></comment></comment><comment><USER17> So when I've called Google Chrome for "spyware" in the past I can now add Chromium to that list.

Google's not even trying to not be evil these days.

</comment><comment><USER18> [https://code.google.com/p/chromium/issues/detail?id=491435](https://code.google.com/p/chromium/issues/detail?id=491435)

This fix is an opt-out with a compilation flag. Also, I don't know much about Chromium development process, so it might be irrelevant, but I only see source updates, without any updates in the documentation.

</comment><comment><USER19> In a web browser implementation with NaCl support, downloading and executing arbitrary binary blobs is very much a feature, not a bug. The issue here seems to be that Chromium was configured, by default, to download and execute a particular Google-provided binary blob. And now it isn't.

Note that as soon as you go to ANY WEBSITE using Chromium, you are entrusting that site to download you arbitrary data, which could include NaCl binaries, which you're then going to trust Chromium to execute.

<comment><USER20> Is this true of Chrome as well?

If so, I will never run it again.

<comment><USER21> They are sandboxed "machine independent" binary blobs that chrome translates into the local architecture, see [https://developer.chrome.com/native- client](https://developer.chrome.com/native-client) for details.

Javascript isn't far off binary in terms of readability nowadays with the level of packing/minification, so legibility isn't a deciding factor. Therefore if you can't trust the native client sandbox, why trust javascript, or even HTML from third parties? Native client is part of Chromium, you can audit the source code just as much as for any other language your browser speaks, so why make this distinction?

<comment><USER20> I didn't even know this "native client sandbox" existed! Why the hell should I trust it, or anything executed inside it?

I'm tentatively willing to believe that Chrome is probably not trying to pwn my box, because I don't think Google has a compelling reason to do that which would outweigh the flak they would get if they were caught. Allowing them to run arbitrary compiled executables on my machine, however, would require me to transitively extend trust to everyone using their technology, and to do that I would have to be confident that there are not and never will be any security holes in their sandbox. That is an unlikely proposition to say the least and therefore I want nothing to do with NaCl.

<comment><USER22> In some instances when served with an NSL (or some other mechanism we don't even yet know about), they can be forced through legal policy to cooperate in building something that pwns your box. Google's compelling reason is that they are under the jurisdiction of the American government. Though I share your tentative belief that Chrome/ium isn't necessarily a "pwn vector" per se, I am 100% willing to believe that they are compelled to cooperate in building some kind of vector for the NSA.

<comment><USER23> You say "they" as in Google, but it would be much more effective to persuade a single developer (and maybe his manager) who can implement such a feature in a open, transparent way (which would display the standard "recording" icon in the omnibar) or in a closed, subversive way (like, this).

Basically lean on "Never attribute to malice that which is adequately explained by stupidity" as much as possible to fly under the radar as long as possible.

</comment></comment></comment></comment></comment></comment><comment><USER24> I opened a ticket in Chromium's Google Code repo, feel free to jump in: [https://code.google.com/p/chromium/issues/detail?id=500922](https://code.google.com/p/chromium/issues/detail?id=500922)

<comment><USER25> Please read the original thread. This was already reported as: [https://code.google.com/p/chromium/issues/detail?id=491435](https://code.google.com/p/chromium/issues/detail?id=491435)

<comment><USER26> I did, the ticket you linked has been closed with 'adding a opt-out flag' as solution. I opened another one to discuss it's behaviour in general, wether it should be:

1) opted-in by default

2) not ask user for permission (or notify him in any way)

3) hide the extension from the extension list

4) record audio without permission

</comment></comment></comment><comment><USER27> The only microphone I trust is the one that is not there.

How sad.

<comment><USER28> There are always microphones, everywhere, all the time.

I remember when I was a toddler and they taught me that Santa's elves and God's angels where spying me to make sure I was good. They later told me it was a lie. It became true soon enough.

Fighting for privacy is impossible. We should fight instead for transparency, that means, spying those with power. And we should fight for equal rights, that means, making it hard for people to hurt you with the private knowledge they have from you.

</comment></comment><comment><USER29> Not sure why everyone keeps saying "binary blob?", I guess it's similar to when people say "TCP protocol".

</comment><comment><USER30> Any idea what is the executable doing ?

<comment><USER31> It's an extension running in the usual extension sandbox with permission to access the microphone. It's the "Ok, Google" implementation. It's a proprietary blob so you'd need to reverse engineer it to figure out exactly what it's doing.

</comment></comment><comment><USER32> Switched to Firefox as the primary browser just to be sure :)

<comment><USER33> There's a comment there indicating that FF has done the same in the past with an H.264 blob.

The conspiracist in me wonders why both these major browsers have downloaded and maybe executed binary blobs. Is it purely a convenience feature in the browser? Is it a secret order? That last question would have been silly a decade ago but we all know it's entirely possible now.

<comment><USER34> the open h.264 blob thing is annoying, but it's supposed to be a reproducible build of open source software.

The reason why there's a blob is because for that binary, Cisco pays the patent licenses.

So you can verify the source for any issues, verify whether it matches the binary, and work around MPEG-LA licensing at the same time (there are caps, and Cisco seems to have calculated that even when running into them, they're still better off with having webrtc support h.264 everywhere).

</comment></comment></comment><comment><USER35> Since these things can be opaque, archlinux updated to disable "hotword":

[https://projects.archlinux.org/svntogit/packages.git/commit/...](https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=c82e0548218e0398c3788730f3a729d714191d0c)

thanks to the maintainer and the FOSS community in general.

</comment><comment><USER36> Another reason to switch to Iridium Browser. It has Google search disabled by default and even if you switch search to Google, Voice search and hot-words stay off until you manually enable it.

[https://iridiumbrowser.de/](https://iridiumbrowser.de/)

<comment><USER37> another one is "Iron browser"

<comment><USER38> Hm, when I try to download Iron's source code ("for Coder"), a Rapidshare page "Our services have been closed. Thank you for your understanding!" pops out. How convenient.

</comment></comment></comment><comment><USER39> The binary blob is targeted at Native Client and so only runs in the google chrome sandbox. There is no security issue here.

<comment><USER40> "Don't worry, it's running as restricted windows user, there is no way it could possibly ever... oh"

<comment><USER41> Sandboxed unknown code is still better than non-sandboxed unknown code.

<comment><USER42> Agreed, but it is not the same thing as saying there is no security issue.

</comment></comment></comment></comment><comment><USER16> I advise not reading that bug, some of the later comments will give you brain cancer.

[https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=786909#51](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=786909#51)

Downvotes? So you agree with this?

"I seriously consider the good faith of an such upstream which does these kinds of things"

"But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or forcibly cooperate with NSA and friends)."

"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."

"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."

Really if you condone this attitude then I can only say...well I won't say it but it isn't nice. Not only that, everyone seemingly ignores the: "Note that the binary blob is executed throught native client, which is not enabled by default" part.

You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.

<comment><USER43> This guy is actually perfectly right. Google doesn't do thing like that by accident. I'm glad there are some sharp guys around to disclose such potentially malicious behavior.

<comment><USER44> Even if malice instead of incompetence is involved, it goes pretty far to call Chromium a "rootkit-downloader" just because it downloads a binary blob.

It could theoretically be a rootkit, but without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.

<comment><USER4> > without any evidence to support it this is like calling someone a murderer > because he went to the same high school as a murderer.

That's a pretty flawed analogy. If you're going to examine it from a criminal act point of view, let's really look at it that way. If installing a rootkit is equivalent to premeditated murder, then the murderer must have motive, means, and opportunity. Let's take Sony as a good example of a company guilty of installing a rootkit. Motive: Prevent unauthorized copying of their music CDs. Means: Rootkit is embedded in the audio CD and uses Windows' Autoplay feature to install itself. Opportunity: They didn't disclose this rootkit so anyone who bought a Sony audio CD during that era was vulnerable.

Now, let's look at what we know about this Chromium binary blob silent install (note I'm not calling it a rootkit, as I agree with you that's taking it a bit far, but it would theoretically be possible to install one via the same method). Motive: Google wants to put the same always-listening "feature" on Chromium installs as well as plain old Chrome. Means: Google writes and publishes the Chromium source code. Opportunity: Just guessing here, but Google releases this change without announcing it (otherwise why didn't the Debian packagers see it right away?).

Now, once again I'm in agreement with you that calling this a rootkit downloader is a bit much. But what if it had actually been a rootkit, inserted by Google either intentionally (I don't trust them, but honestly why would they do something that nefarious?), or without their knowledge or consent (which would mean they are compromised by an outside actor). That is why this is such a big deal, and kudos to the Debian team for finding it.

It also bothers me that this binary blob, while not actually a rootkit, did have the ability to listen to the computer's microphone 24/7 (yes, that is a "feature" as it is part of Google Now), and can't be audited because there is no publicly available source code. That's quite a security hole; I recall discussing all kinds of financial and personal matters with my wife right in front of our computers. Thankfully they are both desktop machines without built in microphones, but many people these days use laptops as their main computer.

To sum up, I don't like it and I think it's a shitty thing for Google to do. Whether it was intended to be a silent install instead of public knowledge, or just a major gaffe, remains to be seen.

<comment><USER45> Seems like the OS should be doing a lot more sandboxing of hardware features. And is Chromium ever run as root? How could it install a rootkit if not?

<comment><USER16> The problem is that a browser does really want access to a whole lot of stuff as it's almost an OS.

But no, Chromium doesn't run as root afaik, the rootkit stuff is complete bullshit.

<comment><USER31> The sandbox binary uses setuid root if user namespaces aren't available, but that's a necessity for making the empty chroot and process/network namespaces used to sandbox tabs. The layer-2 sandboxing code (seccomp-bpf) doesn't require anything like that, but they're meant to be complementary (although both are strict enough that they could act as a meaningful sandbox alone).

<comment><USER16> That's really interesting, thanks.</comment></comment></comment></comment></comment></comment></comment></comment>


Kickstarter campaign to raise $1.5M in 30 days with only $1 pledges - <AUTHOR> https://www.kickstarter.com/projects/1718834732/talk-is-cheap-from-academy-award-winner-barrie-m-o

<comment><USER2> What? There are clearly other options...</comment>


"Let's talk about a hypothetical public-facing service" - <AUTHOR> https://www.reddit.com/r/sysadmin/comments/3do9k0/sourceforge_is_down_due_to_storage_problems_no_eta/ct77o49 <comment><USER2> _> You have a moment where you envision the future of virtualized storage and think about how great it will be when storage is nearly free and outsourceable and you can stop buying disks from Amazon every few months_

The future is now! Instead of you sending money to Amazon and them sending you disks, they keep the disks and you send them the money anyway.

Progress! :-D

<comment><USER3> Sadly, depending on what you want to accomplish with your storage the future is still not here. For example, if you want to share a virtual disk with multiple servers through NFS you will still need to manually create a NFS high-availability cluster using e.g. DRBD on most cloud providers (e.g. EC2 or Azure). To be fair, MS Azure offers fully managed SMB shares as a service, but the transfer speed is quite low (60 MB/s in the best case) so they are not very useful for most tasks.

<comment><USER4> AWS has EFS [1] which should allow you to share one FS to multiple serves. It is still in preview but could help address these needs.

[1] [http://aws.amazon.com/efs/pricing/](http://aws.amazon.com/efs/pricing/)

<comment><USER3> That looks interesting, thanks for the link!

</comment></comment></comment></comment><comment><USER5> _...Extremely Massive Corporation..._

I knew EMC storage was utter shit when, upon attempting to create a new RAID group, I realized that the configuration tool's default was to stripe across drives _within a shelf_ , not to create stripes that _span shelves_.

Worse, to create the more fault-tolerant, shelf-spanning RAID volumes, one must manually add drives, one by one to the array, in a process that involves about 44 (slight hyperbole) clicks per disk.

And then there was the fact that the configuration tool was Windows-only.

Yeah, screw those guys.

<comment><USER6> Actually it sounds like the EMC software was trying to save you from something which is a bad practice. If you want raid 1+0 it is better to have two disks on the same controller/chassis in raid 0, then raid 1 (or raid 5/6) across chassis. Otherwise a chassis failure will take fail both leaves of your raid mirror.

Having said that, EMC is stupidly overpriced bloat.

<comment><USER5> Did I really need to spell out the geometry of the RAID I was creating to avoid this kind of nitpicky follow-up?

It was a 20-something disk RAID 10 [1], arranged so that every mirrored pair of disks spanned different enclosures, in order to mitigate the failure of any one shelf — that is, interleaving mirrors across controllers and shelves, exactly as you suggest I should have done — and further, such that any one shelf failing only affects the mirrors that had disks on that shelf.

EMC's software wanted to allocate the drives from two shelves, with an unequal number of drives per shelf. It was just grabbing the next however many disks, linearly.

So, no, they weren't trying to balance the mirror across enclosures or controllers. They just weren't thinking.

[1] By "RAID 10", I mean "striped mirrors" — that is, create a bunch of mirrors that span shelves and then stripe across them — not "mirrored stripes" which is what you appear to be suggesting, with "it is better to have two disks on the same controller/chassis in raid 0, then raid 1".

A striped mirror is recommended in everything I've ever read on the subject, because it puts the redundancy at the lowest level of the array's geometry.

Using a mirrored stripe, on the other hand, means that when one disk fails, any other disks striped with it, still presumably perfectly functional, can't be used; the controller must instead read from and write to the mirror. If a disk in that mirror subsequently fails, you've lost data — and remember that when striping, the chance of failure is _multiplied_ by the number of disks in the stripe.

EDIT: Footnote.

<comment><USER6> Don't get all upset. You said _stripe_ disks in your first comment, not _mirror_ volumes.

In a big system I am usually more concerned with avoiding any SPOF (that will cause downtime), then adding redundancy for the most likely failures.

Individual mirrored pairs on split chassis will mitigate against long rebuild times for a single disk failure but it requires an all software architecture as the individual HBA can't do hot spare rebuild. It also reduces the benefit of the HBA cache. So intra chassis, striped mirrors; inter chassis, mirrored stripes. Of course, mirroring across striped mirrors would be better, but the cost to peak write and capacity might rule that out.

Also, yes I believe you, EMC sucks. But they do have some good engineers.

</comment></comment></comment></comment><comment><USER7> Got a good chuckle. Such is life in IT. Gotta admit I missed the "Extremely Massive Corporation" hint.

<comment> glass- It reminds me of Douglas Crockford's talk where he mentioned that a company asked him for an exemption to the "do no evil" clause in the JSON License, and he said he didn't want to name the company as that would embarrass them so he would instead give their initials: IBM.

<comment><USER8> It's not embarrassing; their lawyers are just being cautious, as befits a company with huge customers like theirs. The "do no evil" clause is stupid and utterly ambiguous. If Crockford becomes a fundie, then is any gay-related org in violation of the license?

It's his right to make up ridiculous licenses. Like the sisterware license (you can use the software if you send me a pic of your sister if you have one), people shouldn't take it seriously and avoid code licensed like that. That Crockford doesn't get this is either him trolling or being clueless.

</comment></comment></comment><comment><USER9> I was hoping they would stay offline. It's really disappointing to see a good service turn into a money wringing desperation.

<comment><USER10> The way I discovered SF was down was when I was trying to install some Slackbuilds and kept getting MD5 mismatches on the source downloads. I noticed I was getting the same MD5 for several different packages, so I tried to manually grab a package and that's when I hit SF's error page (which _sbopkg_ was happily downloading and trying to pass off as somesourcepkg.tar.gz).

I found myself in the odd position of hoping SF would come back up so I could finish what I was doing, when I'd normally welcome the news that they had shut down.

<comment><USER11> Sadly I too found it was screwed a few days ago when trying to pull some source code hosted there (ironically so I would have my own copy in case things went wrong there...). I just got their 'Disaster Recovery Mode' notice and a subset of binary packages available.

Lots of google searching for what's wrong with Sourceforge revealed nothing (other than complaints about their packaged installers/crapware). Now I have the answer to the question I was really asking.

I just need to wait and see if the developers of the packages I need will somehow migrate to github so I can get the source...

</comment></comment></comment><comment><USER12> SourceForge has posted info about current infrastructure and service restoration activity at [http://sourceforge.net/blog/sourceforge- infrastructure-and-s...](http://sourceforge.net/blog/sourceforge- infrastructure-and-service-restoration/)

[Disclosure: I work for SourceForge]

<comment><USER13> >[Disclosure: I work for SourceForge]

My condolences.

</comment></comment><comment><USER14> > made by an Extremely Massive Corporation who until now you've generally > respected.

As usual, one's respect for BigCompany is inversely correlated to one's use of their products.

</comment><comment><USER15> One can hope that if this hypothetical public-facing service never returns, they will ship the backup tapes to the Internet Archive instead of Honest Bob's Social Data Mining and Market Manipulation.

</comment><comment><USER16> > It writes a full 32 bits of numeric user ID to its filesystem, but to save a > few bytes it only stores 16 bits of group IDs. Some engineer probably > thought that'd be enough for anybody.

I'm having the same issue with the number of hardlinks, which, for linux ext4 systems, is limited to 65000.

</comment><comment><USER17> _' all the knowledge about how to handle this moody piece of hardware is lost, like tears in the rain'_

Offworld, Roy Batty reference.

</comment><comment><USER18> Yeah, they dealt with EMC. That's never going to go well.

(continues reading)

</comment><comment><USER19> "Let's talk about a hypothetical public-facing service that offers tools for collaboration, revision control, and software publishing." \- it was hard not to notice that he was referring to SourceForge. :)

<comment><USER20> You know the title of the Reddit post was "Sourceforge is down due to storage problems, no ETA", right?</comment></comment>


Dyson Ball Vacuum Teardown - <AUTHOR> https://www.fictiv.com/resources/starter/hardware-dna-dyson-ball-vacuum-teardown <comment><USER2> I think many people don't realise the high level of innovation that happens over at Dyson. Before Dyson debuted his cyclonic vacuum cleaners, there was nothing else like them on the market whatsoever. Competitors brought out their own cyclonic vacuum cleaners, but the cyclonic action is only one factor, the other is the high efficiency rates they're able to achieve in their cleaners which separates them from the rest.

Really nice teardown, I would love to see teardowns of other Dyson products. These guys are the Apple of the home appliance world and not many people realise it. To most, a Dyson vacuum cleaner is just an expensive cleaner and to others, they're modern industrial design marvels.

<comment><USER3> You should go to a vacuum cleaner repair store and look at all the repaired dysons that the customers don't even bother to come back and pick up.

Statements like this concern me "It looks like an epoxy was used to weld the 2 ABS parts". I'm not sure "weld" means what they think it means.

<comment><USER4> "Plastic Welding" is term people use. Though it tends to mean chemically bonding the mating plastics.

</comment></comment></comment><comment><USER5> Well-engineered hardware is definitely interesting, but unfortunately this article is rather lackluster. I'm not even talking about the many typos, but absurd claims like the suggestion that the use of Torx screws "Protects Dyson from counterfeit" really should not make it into an article by somebody who claims that they are "engineers, like you".

Their try at explaining the physics involved also does not quite convey they feeling that they understood what is happening and how.

<comment><AUTHOR> When reviewing and optimizing BOM costs, Torx screws are almost 2x the cost of a standard Phillips which helps to distinguish knockoffs. Folks who counterfeit items are looking to maximize profit and will always go for the cheapest items and not many people look at screws to see if they're different. Lots of threads out there about this. Even with this said, and as we pointed out, it's not the main reason Dyson chose Torx screws—the primary reason would have been for proper fastening to ensure a tight assembly that wouldn't come loose.

</comment></comment><comment><USER6> It's interesting to have someone comment on the history of Dyson a little. For me, when shopping for a vacuum, Dyson looks like the Bose of the vacuum world: it works pretty well but is way over-hyped and certainly over-priced. But, I forget/am too young to appreciate that before Bose/Dyson got their bad rap today they were market leaders. Gotta keep that perspective sometimes.

<comment><USER7> I have a 7 year old Bose radio that still sounds friggin amazing and looks better than me most days. Worth every penny.

<comment><USER8> I think the "bad rep" might be (in my own part of the world) that they are overpriced for the quality. The quality is good, that is true with the Bose system in my 2001 Maxima, but it is probably not a bang for buck equivalent of its.. off brand equivalent.

<comment><USER6> That's what I was trying to get at. My experience too has been that they are fine enough systems but they cost to much and I have little patience for their advertising. I bought an amp and speakers almost a decade ago now which were not Bose and they are also going strong. Except this system was a fraction of what I could have paid for a Bose.

I get it too, that when buying a Bose it's like buying a Mac: you just have to shell out the money and all the though of making a computer is abstracted from you. It can be cheaper if you piece a PC together yourself but not everyone has time or patience for that. Paying for Bose is paying for something that 'just works'.

</comment></comment></comment></comment><comment><USER9> Pretty interesting why they use the 6 point Torx screws: -They won't strip during assembly -Protects Dyson from counterfeit -Makes it difficult for customers to disassemble their products

Never thought about using them to distinguish counterfeit products.

<comment><USER10> > Makes it difficult for customers to disassemble their products

I've always found this a strange assertion. Decades ago perhaps this was true, in that such bits were a touch obscure and required a search. Except in my case, where I tagged along with a friend to a HAM show and picked up a set of security bits on a lark. _That_ turned out to be terribly useful over the years.

Even a pretty standard multi-bit set (say 20-24 bits and a driver handle) I got ages ago had several sizes of torx bits. These days, any half-decent hardware store stocks torx drivers and bits it seems. That's not even counting what I'll imagine is a few clicks online to obtain virtually any bit needed.

</comment></comment><comment><USER11> If this really was reviewed by Dyson, I'm surprised no one picked up on this mistake: "Due to good ol' conversion of energy". Conversion should be "conservation".

<comment><AUTHOR> Fixed it! You'd be surprised what can get past your eye after reading an article over and over again... :)

</comment></comment><comment><USER12> Impressive to see the complex engineering and manufacturing that goes into something we see so "simply" as a vacuum.

<comment><USER7> To take that idea a step further, you'd be really impressed at the complexity on the other end of the power cord. I once heard it put like this...

Nuclear power plants (I suppose you could say the same for any other, but this example was given using nuclear power) exist basically so that, a few miles away someone can plug their vacuum cleaner into the wall, hit a switch, and have it work, without having to give it any thought whatsoever. All the complexity of nuclear power, so that you don't have to think about it.

I think this analogy is especially appropriate here, as the design goals of Dyson are similar. Intense engineering so that you have something that does a simple job exceedingly well without additional problem solving required by the user.</comment></comment>


Fetishizing Programming Languages - <AUTHOR> http://pathdependent.com/2010/05/01/fetishizing-programming-languages/

<comment><USER2> Wow, I disagree with this so much that it makes me realize I don't accept that a programming language is a tool. A compiler is a tool. A language is a _medium for thinking_. Different ideas arise when working in different media. This leads to a thousand different little decisions about how to move forward, resulting in different programs - potentially vastly different.

Technically, of course, these languages are all equivalent because you can write an interpreter for one in another. But that also implies they're not equivalent conceptually; that's what "interpret" means.

The influence of the medium on the program is so acutely obvious to me that I wonder how anyone could miss it. Here's one thing I think obscures it: when we compare programming languages, it's almost always by juxtaposing implementations of a program (or code snippet) that we already know how to write: something clearly defined and well-understood. But this is precisely when you're least likely to be influenced by the medium. (Someone porting, say, the Mona Lisa to watercolor, or fingerpaint for that matter, doesn't have to make big decisions about what to paint: it's clear what the picture should look like because it already exists.) It's when you _don't_ yet know what the program should do, or what direction it should evolve in, that your ideas are going to be deeply conditioned by the medium in which it has evolved so far.

In other words, the way we compare programming languages is designed to overlook all the most interesting and subtle differences between them. Maybe that's why people come to the conclusion that language doesn't matter. Every time I hear that I wonder how deep that person has really gone. One wouldn't think much of an artist who said that medium doesn't matter.

<comment><USER3> Well said. I like Ken Iverson's phrase for this (and lecture), " _notation as a tool of thought_ ".

</comment></comment><comment><USER4> _Carpenters don't seem to suffer from the same error of judgement. There might be several brands of hammers offering slightly different features, but they all pound nails into wood._

Awful analogy. Software is like capentry (in the small) and architecture (in the large). In both cases materials matter. A language is the material for building a particular kind of structure, not only a tool for building that structure.

Consider the fact that many programming languages fail miserably at concurrency. Is that because you don't know how to use the hammer, or because you picked a really bad material for building that particular kind of structure?

EDIT: Thought about this some more, changed my negative slant on carpentry. Furniture is a delicate and beautiful sculptural practice. In carpentry materials matter just as much.

<comment><USER5> The software and CS fields are also relatively nascent. Programming languages today are arguably better than the ones we had available to use 20 years ago, whereas a hammer you buy today is pretty much as good as one you could buy 200 years ago.

<comment><USER6> Yeah,the wooden shaft of 200 years ago is hard to beat. There have been some ergonomic improvements in high-end hammers [http://www.stanleytools.com/xhtml/literature/StanleyHandTool...](http://www.stanleytools.com/xhtml/literature/StanleyHandToolsCatalogHammers.pdf), but simple metal shafts are actually a step backwards.

</comment></comment></comment><comment><USER7> I think what the author is driving at is: when multiple programming languages exist _in the same space_ , it's not a very effective use of your time to learn all of them.

If you know Python and Perl and you teach yourself Ruby, you probably won't learn very much. If you then teach yourself Lua, Javascript and PHP, you'll learn progressively less each time.

I was surprised to see this particular brand of negativity in the comments. I thought the post was trivial, not controversial.

</comment><comment><USER8> > there exists a danger of conflating learning new languages with learning new > ways to solve problems

Example: When you come from a C background and you discover declarative or more specifically functional programming, how is this not a new way to solve problems?

<comment><AUTHOR> _However, once you are familiar with the broad paradigms, there exists a danger of conflating learning new languages with learning new ways to solve problems._

By paradigms, I mean programming language paradigms (e.g. functional programming, class-based object-oriented programming, generic programming, etc.) The danger comes from learning _many_ languages of the same class for the sake of learning them. There are other areas of programming that would be more beneficial to learn, given limited time.

</comment></comment><comment><USER9> "Learning a set of very similar languages is of limited utility because your not actually gaining anything new."

This might be true if you completely diminish the importance of syntax. Likewise, there is a lot to learn from those little gaps between where any two similar languages diverge.</comment>


Developer Preview: RethinkDB Now Available for Windows - <AUTHOR> http://rethinkdb.com/blog/rethinkdb-windows-preview/ <comment><USER2> Congratualations to the RethinkDB team on this! I'm sure it was no small feat to get RethinkDB running on Windows and between this and the Jepsen results, they are clearly doing very well right now.

<comment><USER3> The only problem seems to still be name recognition, though I assume that will come with time.

Not enough people know that Rethink exists, and is a fantastic choice for those looking to use a document store in their architectures.

<comment><USER4> Just my take:

I really don't like RQL. Why couldn't it just be a document flavored SQL? Having a DSL for writing in-database procedures is fine. But tying all external queries to a Builder is, from a purely aesthetic POV, pretty ugly IMO.

But that can be addressed down the line I'm sure. If nothing else by other people just building new DSLs on top of the Builder interfaces.

(Note: Yes, I realize the Builder supports map/reduce as well. In practice I'm skeptical how well that works in an on-demand fashion.)

Having only one fully-managed host available is a minor negative. Though we use Cloudant right now so that's a bit hypocritical perhaps.

Lack of integrated full-text search makes things (application-side) a lot more complex than Cloudant or a traditional RDBMS with integrated full-text search. Maybe not in a "look what I can do" prototype-ish phase, but definitely in a "what would Jepsen do to my system" sort of scenario (see the "Warning" here: [https://www.rethinkdb.com/docs/elasticsearch/](https://www.rethinkdb.com/docs/elasticsearch/)).

That means you're going to want to routinely compare and reindex. Which ugh.

That's just my 2c on why I'm not super excited about RethinkDB. Doesn't seem a whole lot to differentiate it from other NoSQL databases outside of being a better MongoDB. It doesn't integrate full-text-search like Cloudant. It doesn't have transactions. It's got this streaming thing. Which seems like a pretty niche feature. But maybe that's just me.

It is free though, so that's definitely something. If I were a cash-strapped startup that might be enough to move it near the top of my list. OTOH if I'm paying for a fully managed, hosted service that matters a whole lot less.

Feel free to educate me. :-)

<comment><USER3> I've said a lot on the subject, but for me the top benefits that come to mind are:

\- Built to be distrubted (sharding and replication are super ez to use)

\- Easy to use admin interface comes built in

\- RQL (which is a minus for you, as you noted)

\- Joins

\- Streaming (you're right, but I think this niche grows bigger by the day)

\- Functional chaining interface, with lots of nice utility functions

\- Geospatial commands (this is oft overlooked, and another really awesome thing it does, check out [http://rethinkdb.com/api/javascript/#circle](http://rethinkdb.com/api/javascript/#circle))

If I were to summarize your points:

\- RQL is not that compelling, DSL is preferable

\- No full text search

\- No transactions

(please correct if I've missed anything)

The DSL problem is probably relatively straightforwardly fixed (just write a DSL that translates to builder calls), but I think that RQL sprung up from a disdain of DSLs that were built by mongo (and probably in some part SQL), that often become overly complicated, hard to use, and sometimes use obtuse/hard- to-remember terminology.

The other missing-add-on points are valid of course, but they're just about as equally valid for any document store you can find. I don't speak for RethinkDB, but as far as I can see they do not claim to offer those things, so I don't know if it should be held against them that they don't. Of course, it makes sense that you're not super excited for it because of those missing features you want.

However, I think you'd be hardpressed to find another document store that has gotten the rest of the things it does as right as RDB has gotten them. RDB has iterated their way to a really high quality document store, yet (I find) does not get the press to match how well it performs (and how many big pitfalls it avoided).

<comment><USER5> > However, I think you'd be hardpressed to find another document store that > [...]

CouchDB. Older by 6 yrs, so probably can't compete with RethinkDB on wow-yet- another-new-fresh-backed-tool-with-fancy-webpage-and-admin-ui scale ;)

In everthing else couchdb has more features than rethinkDB. And is much more mature, but somehow this word is understood backwards these days. Technology ageism I suppose ;)

p.s. I'm not couchdb dev/supporter etc.

<comment><USER4> CouchDB doesn't do joins, which can impose serious schema design changes depending on your application. map/reduce is done at index time. You wouldn't ever want to do it on the fly.

The base CouchDB also wasn't clustered last I looked (a year ago maybe?); you had to use BigCouch, which was an OSS contribution by Cloudant that lagged both Cloudant's own offering and CouchDB releases. It was supposed to get merged into head though so there's a good chance that actually happened while I wasn't looking.

If you're just looking at CouchDB though and not Cloudant, it's not all that compelling (IMO). No clustering. No integrated search. No transactions. No joins. Pretty shallow server metrics in the dashboard. CouchDB doesn't even really have queries AFAIK. Just index scans.

</comment></comment></comment></comment></comment></comment><comment><USER6> Not in love with MongoDB, DocumentDB is Azure only. Finally a (great) document database option for me (I work in a .NET shop). Kudos to you guys.

But... but... what's with that C# API? It doesn't look like typical C# at all.

<comment><AUTHOR> Slava @ RethinkDB here.

You might want to look at [https://github.com/mfenniak/rethinkdb- net](https://github.com/mfenniak/rethinkdb-net) (this is an alternative C# driver with a different API). We'd love to get an official C# driver in soon, so if the community has suggestions on how to improve the API (and which driver feels more idiomatic), we're all ears!

<comment><USER6> From a quick glance, this one you just posted feels way more idiomatic than the Java port.

The ultimate idiomatic thing to do would be to expose rethink as an IQueryable<T>, but implementing it can get hard/tricky.

[https://msdn.microsoft.com/library/System.Linq.IQueryable](https://msdn.microsoft.com/library/System.Linq.IQueryable)

<comment><USER7> That would be amazing, but potentially also misleading.

My 2 cents for Slava & co: The idea of IQueryable<T> is that it implements all LINQ "operators" (a weird LINQ term; they're just methods on an interface) just like IEnumerable<T> does it on in-memory data structures. But internally IQueryable<T> implementations typically build an SQL query instead.

So IQueryable<T> is designed for a use case somewhere halfway between an SQL query builder and an ORM.

I don't know ReQL well enough, so you'll have to assess this yourselves: If you can map all or most LINQ operators into ReQL, then you _have to_ do the effort and implement IQueryable, it's too awesome an opportunity to let go.

But if the match is only, say, 50%, plus there's a couple of things Rethink can do that isn't easy to express with LINQ, I'd _strongly recommend_ not implementing it at all, but designing your own, C#-flavored, query interface that just _resembles_ the LINQ operators wherever possible (e.g. use "Where" instead of "filter").

Thing is, developers expect that anything they do on an IQueryable is transformed into a single gigantic query and optimized and executed once, on the database. Maybe Rethink can't guarantee the same performance characteristics, simply because it's no relational SQL-ish database. It would have to implement certain parts of IQueryable in client-side memory just to be compatible. Do that, and you'll end up fooling a lot of developers and they'll have a hard time finding out where their speed went. The other option is runtime NotImplementedExceptions for all unsupported methods, which really is just as unfriendly.

<comment><AUTHOR> Thanks guys, that helps a lot!

</comment></comment></comment></comment></comment><comment><USER8> This is one of those databases I wanted to eventually arrive on Windows, I really enjoyed the look of it and wanted to try it out, and although I have used from time to time Linux as my main OS I just don't feel comfortable using a database I can't run on multiple platforms, it seems like a barrier not being able to use it locally from Windows, although Vagrant and vagrant boxes like Scotch Box are making this "issue" a little less relevant these days, it's still nice to be able to run a database without installing an entire OS. Thanks for the work and time invested in bringing Rethink into Windows, it is truly appreciated.

</comment><comment><USER9> As mostly a Windows developer nowadays, many thanks and congratulations.

</comment><comment><USER10> _many of the underlying design decisions in libuv clash with decisions that we've made in the RethinkDB core_

Can you expand on this please?

<comment><USER11> RethinkDB uses custom abstractions to hide the lower-level OS-specific code. We were able to port the low-level code to Windows with very little changes in these abstractions, and thus minimal changes to the rest of the code base.

The proper way to use libuv would be to replace those abstractions with libuv's own, which would affect a lot more code and possibly break a lot of implicit invariants.

In retrospect, perhaps we should have given alternatives like libuv, libevent or boost::asio more consideration.

</comment></comment><comment><USER12> I love how they're reaching out to C# users (and conversely I love how MS is reaching out to Linux and OS X users by opening sourcing their CLR, giving away their IDE, integrating Node.js and JSX as first-class citizens, etc!) but Rethink-ers if you're reading this - I briefly perused your source code and to a C#'er (who has written his fair share of JS, both in the "Visual Studio ASP.NET and SharePoint" style, as well as the "node.js" style) -- this doesn't read like idiomatic C# at all. I'm sure it works well, but the API feels like someone who writes JS for a living was given a deadline to add this feature and tacked it on half-heartedly.

There's no reason in this day and age that you should be have any deps on stuff like Cygwin, which you claim you don't: >> _You won't find any POSIX compatibility layers or other similar hacks–RethinkDB uses native Windows APIs on the Windows platform._ It looks like you do[1] from the whole Cygwin section and the env var's you have to add to PATH (in a somewhat inelegant way). That dependency "tree" is... extensive to say the least and a lot of it can be eliminated or eased with a combination of NuGet and chocolatey. Having in your instruction notes to build Goog's RE2:

>> _Build it somehow (I forgot to record how)_ [2]

doesn't really make me too confident that you're going to support Windows as a first party platform.

The API exposed to the end-user should be conventionally written in a more LINQ-y way - I.e. Fluent style code should be written with Object.Blah().Filter(x => x % 2).ToList() or whatever. Just little idiomatic things like that are pretty pervasive.

Regardless, thanks for investing the time on working for this. As a curmudgeon and someone who spends his spare time reading journal papers in the ACM about concurrency models from hardware transactional locks to ICFP papers which implement similar concepts on the exact opposite side of the spectrum, it's my duty to be wary of new technologies and slow to adopt them into production-- but RDB and VoltDB are two products I really think are technically sound. Contact me if you want a more thorough critique to make this more idiomatic, because your product really is great!

[1] [https://github.com/rethinkdb/rethinkdb/blob/a90bb08051603621...](https://github.com/rethinkdb/rethinkdb/blob/a90bb0805160362125a03024eb9f309e578408c0/WINDOWS.md) (Errata: see _edit_ )

[2] See [1]: RE2

Edit: I was referring to this revision of _Windows.md_ , which at the time was what was available on their master branch. My critique largely revolves around that version. Proceeding my post, another branch's version was swapped in, to a more clean version in which the build phases of the dependencies are removed, and replaced with pre-compiled binaries as you now see: [https://github.com/rethinkdb/rethinkdb/blob/next/WINDOWS.md](https://github.com/rethinkdb/rethinkdb/blob/next/WINDOWS.md) This solves the aesthetics issue but just pushes the problem into another domain. You're using binary deps (some of which are cygwin'd afaik, but I haven't taken IDA to it so I can't say definitively) but if you want to build from "source" a la the FreeBSD ports way -- where every single .c or .cc is available for one to see and modify as their environment demands -- the problem's still there just pushed under the rug.

<comment><USER13> You might want to check out the new Windows build instructions here: [https://github.com/rethinkdb/rethinkdb/blob/atnnn/windows2/W...](https://github.com/rethinkdb/rethinkdb/blob/atnnn/windows2/WINDOWS.md)

We've since simplified the build process, and it can now build most dependencies automatically. The only exception right now are the web UI assets which still need to be downloaded separately or copied from Linux (building these on Windows will come later).

We don't link or compile in any Cygwin code, and use all Windows APIs directly. The build system uses some Cygwin tools though. Incidentally we considered using Cygwin to achieve Windows compatibility at some point, but found that it didn't implement some of the lower-level APIs that RethinkDB uses on Linux.

</comment></comment><comment><USER14> A little bit off topic but what is the meaning of "developer preview" in the context of an open source developer tool project?

edit: speling

<comment><AUTHOR> Slava @ RethinkDB here.

"Developer preview" means we're still going through internal testing processes. The code review is still in progress (the windows port hasn't been merged into next yet), and the build hasn't been widely tested in the wild.

Everything seems stable and there aren't major known bugs, but there is still work to do before we can label the windows port production ready.

<comment><USER14> A developer preview is a prerelease of a user software package that's potentially a platform for other software, targeted for developers who would potentially build applications for the package's user base. An OS like windows may have development previews, as tgerr would be developers who would want to start early to develop apps on tge platform. Sublime text may release a development preview in order to allow developers of plugins to start early to update thir plugins to the new version. But a database is not a user application, it is a developer's tool or a component of an application. Thus a developer preview of a thing that will never directly face a user is not logical. You want to say release candidate or simply beta instead. Developer preview implies extensible user application.

<comment><USER15> It's a preview and it's for developers.

<comment><USER14> Bravo, you're smart enough to read. Now try to think.

I thought that the phrase was misleading, and I gave feedback. No need to join in with a _cool_ slap to me.

</comment></comment></comment></comment></comment><comment><USER16> your mascot is adorable.

<comment><USER17> Wait 'til it puts on its robe and wizard hat!

<comment><USER16> haha, it's more that it's rare that I see such detail put into ui/ux/branding in many/most products, especially ones that aren't geared toward common end users. big kudos :)

</comment></comment></comment><comment><USER18> Does it make any sense from licensing point of view to host database on windows if there is a Linux version available? As far as I understand each user hitting that database directly or indirectly via an app needs a CAL for that Windows Server. Outside of an enterprise (ie. Cloud) it gets veery expensive quickly.

Enterprises embraced Linux long ago so not sure if rethinkdb will have much ROI on this effort.

<comment><USER7> The HN filter bubble sometimes forgets this, but there are a lot of developers out there who use Windows (even if they don't always deploy to Windows).

Not having to set up a vagrant box just to give Rethink a try may seriously influence developer adoption in this space.

<comment><USER19> Also while I might personally be able to get by running my DB on a linux VM some friends I'd like to share my apps to run for themselves aren't OK with linux at all.

The docker rethinkdb images made this a breeze but only helps my development.</comment></comment></comment>


LZ4_8088 – Fast LZ4 decompression for the 8088/8086 CPU - <AUTHOR> http://www.oldskool.org/pc/lz4_8088 <comment><USER2> _For source material that contains long runs of sequences (RLE), decompression is faster than memcpy._

This is not surprising given how RLE decompression works --- memcpy and regular LZ decompression requires copying data, i.e. a memory read followed by a memory write. RLE only requires a read of the value to be repeated, followed by multiple writes.

It is interesting to note that CPUs today are also often limited by memory bandwidth, just like the 8088/8086.

<comment><USER3> I wonder how 8-channel memory is going to change that on next gen server chips.

<comment><USER4> Memory is orders of magnitude slower than the cpu at the moment, so you'd need orders of magnitude more bandwidth to come close. So sure, it's going to be faster, but the cpu is still going to be waiting for memory more than the other way round.

<comment><USER5> I wonder if the heat-bound nature of especially mobile CPUs these days could contribute to memory "catching up" to CPU performance. That is, the CPU idle while waiting for memory could be seen as necessary for heat dissipation and so you could consider the CPU at capacity.

<comment><USER6> That's basically what I understand the idea of "race to halt" to be. Mobile CPUs are already designed to finish their current task as quickly as possible so they can idle to cool off (that's how laptop chips can support turbo boost).

I think the time it takes for memory reads is too short to take advantage of though, because of how long it takes chips to come out of sleep & ramp up their clock speed.

</comment></comment></comment></comment></comment><comment><USER7> They're comparing LZ4-HC with something like zlib. They should compare against Google Zopfli instead of plain zlib (or equivalent). But yes, algorithmic improvements and encoding on a modern CPU mean you can do decode on ancient hardware that seems magical, like 8088 Corruption (from the same people, it seems).

<comment><USER8> Code up an assembly language version of Zopfli and we'll be able to compare the two then! Anything else won't be a fair speed comparison.

If you're just interested in compression ratios, there are already plenty of websites that compare them all.

<comment><USER7> zopfli is just a compressor for the standard DEFLATE (zlib) format, able to make png, gzip and zip files a bit smaller. It spends a lot more CPU time doing the compression to achieve marginally better compression ratios (i.e. it's like "gzip -99"). It's worth it to crunch minified js and css files (and serve them as pre-compressed "content-encoding: gzip") and png files to make a popular site load a bit faster.

There is no need for special decompression code, in fact that's the whole point: an unmodified DEFLATE decompressor can decompress the file, even though it is smaller than what "gzip -9" can produce.

They are compressing using LZ4-HC which is a slow compressor. They compare it to something like gzip. They should compare it to something that produces gzip-compatible data but spends even more CPU time to get even better compression ratios.

<comment><USER8> And what I'm saying is that the thing they are comparing it to is something which has optimised 8086 assembly code for the compression. zopfli doesn't, which would make a timing comparison pointless.

<comment><USER7> They only implemented a decompressor.

</comment></comment></comment></comment></comment><comment><USER9> Impressive speed. Having that in the 80's would be having much faster load times and much better graphics.

<comment><USER10> I had an XT clone in the 80s (bought in '87 if I'm not mistaken) & I don't really recall these being a factor on the PC at the time...PC drives were actually relatively fast and CGA/Hercules-era graphics were primitive enough to have put a pretty harsh upper bound on the kind of graphics you could do anyway.

This was very different to the c64 or atari 8 bitters for example (both of which had decent graphics and abysmal floppy performance).

<comment><USER11> > I had an XT clone in the 80s (bought in '87 if I'm not mistaken) & I don't > really recall these being a factor on the PC at the time...PC drives were > actually relatively fast and CGA/Hercules-era graphics were primitive enough > to have put a pretty harsh upper bound on the kind of graphics you could do > anyway.

PCjr CGA+ (adopted also and popularized by Tandy, often known as TGA) graphics were introduced in 1983, EGA graphics were introduced in 1984, VGA in 1987, and there were a number of less-standard higher-resolution and/or higher color modes available and supported in software in addition to those.

<comment><USER10> Yeah but VGA wasn't popular until at least '90 and EGA probably not much earlier, around '88 maybe (before that you'd probably be more likely to have a c64 than a better-than-CGA PC compatible).

Most people didn't have state of the art computers, a PC AT with EGA & color monitor costed close to $10k in 1984 (1980s dollars!). Going to the mall to play on a color monitor was a thing kids were doing back then.

Can't speak much about Tandy as I think these were mostly only popular in America. In Europe you'd still be playing mostly in CGA well into the 2nd half of the 80s, and the only popular PCs until close to the end of the decade were cheap XT clones with CGA at most, or monochrome Hercules more commonly.

Anyway I'd concede that it would have probably made a big difference to graphics fidelity in the very late 80s or early 90s. But I think a lot of people forget that warp-speed improvement of PC hardware and plummeting prices were more a 90s than an 80s phenomenon - in most of the latter we were still in the flat stage of the S curve!

<comment><USER12> I remember most people switched directly from CGA to SVGA in the early 90s. I only remember a couple computers with EGA at friend's homes, and offices were mostly CGA and Hercules too (if they had PCs at all, and not 3270).

<comment><USER10> This was definitely my personal experience, when my brother in law bought a 286 in '91 it already had svga despite only being 4 years newer than our xt.</comment></comment></comment></comment></comment></comment>


Rails has Two Default Stacks - <AUTHOR> http://words.steveklabnik.com/rails-has-two-default-stacks <comment><USER3> Using Steve's definitions from the article, the tutorial I usually point people to is Michael Hartl's Rails Tutorial <http://ruby.railstutorial.org/> which uses the "Prime" stack. I believe I read somewhere that Michael was going to come out with a "37 signals" stack version as well.

One message I'd like people to understand when they're starting out with Rails is that it really is confusing, and that being confused and maybe even feeling stupid is normal! I remember hearing people talk about how easy developing Rails applications was back in 2006, but what I didn't know was it was easy relative to other web frameworks at the time. It's still hard.

By analogy, if you're an intermediate skiier and you visit a well-groomed mountain with great, powdery snow you could say "this mountain is easy to ski on". But if you're just learning to ski, and you follow everyone else up the lift to the top of a blue run, it's a terrifying experience trying to get down the slope without breaking your neck. To add insult to injury, it's discouraging to see everyone else gliding down the slope while you're shimmying down on your butt because when you try to stand you lose control, go way too fast, then crash. New skiiers need bunny hills, then green runs, then blue runs.

I still don't think there's an established "bunny hill" and "green run" track for learning Rails. Sure would like to help someone create one.

<comment><USER4> I disagree that using Rails Tutorial as a beginner resource is the way to go.

In fact, I used that as my first resource for learning Rails! Here are some problems I found with it:

1\. It teaches you Git along with Rails. Who cares about source control at this point? Remember: This is for a newcomer to Rails that just wants to learn how to create websites using rails; don't confuse me even more.

2\. It teaches you how to deploy to Heroku. Again, don't care at this point.

3\. It teaches you how to deploy your code to Github. Once again, NEEDLESS INFORMATION AT THIS POINT! :P

4\. Unit testing; Ugh, I'm 100 pages in and I barely have a grasp of what I'm doing, and I'm STILL barely 1 controller with 2 actions in.

\---

There are other alternatives that I think are better for a newbie.

I will concede that Michael's tutorial IS GOOD, but just not good for someone brand new to ruby and rails. I find myself re-reading Rails Tutorial and The Pragprog Agile Rails book every couple of weeks, discovering new things I missed.

 __That's __the way to learn, keep reviewing things.

<comment><USER3> Interesting. I might be persuaded to recommend something else. What alternatives do you think are better?

<comment><USER4> I haven't found a good starting point. The two main contenders I've read in non sequential order:

1\. Micheal Heartl's Rails Tutorial. 2\. Pragmatic Programmers Bookshelf - Agile Rails 3.2 (4th Edition)

Both are a good start but delve far too much into unit testing with the horrific RSpec. When you're learning something new, you don't want to muddle with learning a DSL on top of things.

</comment></comment></comment></comment><comment><USER5> How do these two options stack up to just not using Rails and using something like Sinatra instead for beginners? When I started with Rails, I spent 2 days figuring out the standard web framework functions / workflow, and then I gave up. When I picked up Sinatra, the pieces were small enough that I could learn them individually, master them, and learn how they were put together. Then, when I came back to Rails, I had a better understanding of the underlying technology and I was able to be much more productive.

Just my two cents.

<comment><AUTHOR> With Sinatra you have absolutely no guidance as to what's good and what's not: there's no stack at all.

I, too, am a bottom-up learner, but most people (in my professional experience) are not. Look at the success of Rails Girls, for example: beginners get waaay more excited and engaged by Getting Something Up There than they do learning the intricate details of HTTP.

<comment><USER6> >beginners get waaay more excited and engaged by Getting Something Up There

Yes! That's why...

        require sinatra

        get '/hi' do
          "Hello World!"
        end

...is so amazing for newcomers.

Even the file structure of rails is a bit too much for begineers. Everything in one file is so much simpler for trivial beginner "get excited" apps.

Introducing someone to rails, they have to learn MVC, a templating system, an ORM, and more.

<comment><USER7> It's amazing for newcomers who like elegant code that can't be shipped. I'm that way. Or, rather, I was, and I look back on that time fondly.

Other people who get into web development aren't impressed by such things, and would rather see something like rails or WordPress which is shippable right away and then can be built on top of.

Some programmers, especially the kind to hang around on HN, would rather not work with people who don't understand the entire system they use. I often hear people say they wouldn't touch WordPress with a 10-foot pole. They are avoiding a huge part of the web development industry. This is a valid choice, but some people don't even realize they're making this choice, and I wish they would realize it so they could make sure that it's really what they want.

<comment><USER8> > Some programmers, especially the kind to hang around on HN, would rather not > work with people who don't understand the entire system they use.

There's a reason for this. I've worked with people that don't understand how things work and don't really want to learn. These people cause enormous amounts of damage in any system that contains architecture beyond php in the webroot and algorithms beyond brute force.

You let one of those people on a large production database, it's game over. They will run queries that miss all the indexes. They will remove constraints because they don't understand why they exist. They will use flat files in place of a database because the database is scary and then not understand why stuff goes missing in the multi-server production environment.

These people are a liability in a project beyond small scale. They are the same people whose wordpress blogs are repeatedly hacked.

</comment></comment></comment></comment></comment><comment><USER9> This is one of the strongest arguments I've seen for simply starting with the "default" stack. Move to other stuff when you feel the pain. If you're teaching or just starting off with Rails, don't use the "Prime" stack stuff until you really need it.

<comment><AUTHOR> One of the things that got me thinking about this was the recent security issues. I was helping people on Skype upgrade their apps, because they were new, and they got into Gem Version Hell. Only pulling in fancy gems when you need it helps when you _really_ need to upgrade, and you're not stuck figuring out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example, obviously, it could be any combination of gems) all refuse to get on board.

If you're using the default stack, the number of dependencies you have drops quite a bit.

<comment><USER10> > twitter-bootstrap-rails, therubyracer, and libv8

Those three gems recently caused me a world of pain. I've been in and out of Rails development since the 1.x versions (more hobby projects than professional development), and once getting going was as simple as 'gem install rails'. Getting the asset pipeline to work changed that totally - <USER2> get the advantages of the asset pipeline, and once you get it working and all your gem dependencies sorted it is fine, but it took me a while to get there.

<comment><AUTHOR> I don't even use therubyracer at all any more, personally. It's not generally neccesary; just {brew,apt-get} install nodejs and be done with it.

</comment></comment></comment></comment><comment><USER11> _This is quite different form the Python frameworks ecosystem_ : here most "beginners" already know Python, or at least they already know how to program having experience in something like Java, C# or C++. And because they already have this knowledge, they usually ending up doing things "their own way", or they already know what each piece is supposed to do before starting to play with a framework that has all the pieces in it.

And "being explicit" rather than "convention over configuration" really helps people make their own choices. When people bump into the limits of Django's ORM, for example they quickly replace it with SQL Alchemy, when they do something in Flask, they already know what the pieces they are putting together do.

Rails culture seems very "top down", i.e. people start learning and doing things by learning the stack as a whole and then about the options for individual components. This leads to "elegant solutions", but tons of pains for beginners that need to "swallow it whole".

I don't know which way is better, but I've always been attracted to the Python ecosystem because I like learning things "bottom up", e.g. playing with all the different pieces and then assemble them into a whole once I'm confident I understand them.

</comment><comment><USER12> For the people who've ended up on the delta/Prime stack it's because they've already _done_ the 37Signals stack, found where it works and where it doesn't, learnt their lessons and found something that works better for them. The problem is when they espouse it as the One True Rails Stack it muddies the waters for newbies, and people who've been building quite happily with the defaults and just need some more information.

Your choice of stack is great, and it's great you're passionate about it but if you start acting like a giant dick about it you're actually dissuading people from getting more involved, and that's not a good thing.

</comment><comment><USER13> Interesting observations. I tried to get back into Rails last year with version 3.1/3.2 after being "away" since sometime when it was still at version 1, and while I've been somewhat successful at it, the choices -- not just between the stacks but between the myriad of different "standard" gems -- can be somewhat paralyzing. Do I use a a Twitter Bootstrap gem that will be easier to manage but might be less customizable than using "pure" Bootstrap? If I switch from ERB to Haml, do I worry about generator gems? Do I want to use Devise for authorization or just use the built-in has_secure_password? Do we love factories now, or hate them? I'm building a CMS-ish sort of thing and it'd be nice to have an automatic admin system like Django does. RailsAdmin or ActiveAdmin? Wait, these _expect_ that I'm using Devise, unless I change something somewhere? Argh.

All of this is pretty simple _once you have preferences established,_ but figuring out those preferences can be enough to drive you back to something that, well, has less choices. (Like the aforementioned Django, although it has its own issues with setup and documentation.)

</comment><comment><USER14> Having overseen ~100 beginners, who didn't know how to code, evolve into rails developers, I can faithfully say the following:

1) Beginners need to listen to one person's opinion and trust them

2) Learning about the people and community around your tools is paramount.

#2 will allow them to advance past whichever stack #1 places them.

There are, of course, other caveats. For example, when a beginner finds an answer to their question on stack overflow, but the example code uses HAML instead of ERB, they need to have a foundation deep enough that allows them to at least recognize the code without feeling lost (or use those "lost" moments as opportunities to educated them about that feeling, which is rather normal for a beginner in anything).

Etc.

</comment><comment><USER15> What would help Rails the most is probably some example projects. They could be anything ranging from simple twitter clones to maybe full on e-commerce stores or something. Build them using the "golden path" and maybe someone else could build the same thing using the "prime" stack.

When I started the Obvious architecture, writing an example app made it concrete and makes it a lot easier to explain particular details or structures to people wanting to learn.

People love examples.

<comment><USER16> These example Rails app tutorials look promising: <http://railsapps.github.com>

I'm still working through Michael Hartl's tutorial, but plan to work through each of these afterwards.

</comment></comment><comment><USER17> I seriously wonder why people still use haml over slim. Slim imho is the best templating language around. It should replace haml in this so called 'prime' stack.

<comment><USER18> Actually, having used HAML for a while, I got really annoyed with it and switched back to HTML. I like the prime stack + plain old ERB.

</comment></comment><comment><USER19> _Someone told me earlier today that 'Starting Rails today is like starting to watch a soap opera in the 7th season.' Like most witty statements, there's both truth and falsehood here. But, as a newcomer, how do you pick between the 37signals Stack and the Prime Stack?_

How many parts of Rails can you swap out before it stops being Rails?

Maybe the simplest solution here would be to call the Prime Stack something different. Even "Rails Prime" would work. Just some nomenclature that says to people "hey, just so you know, what I'm going to talk about here is different than what 37signals is talking about."

<comment><USER9> > How many parts of Rails can you swap out before it stops being Rails?

Rails is meant to be modular, it just doesn't stop being Rails.

<comment><USER20> Actually the answer was 7.

<comment><USER21> I was going to guess 42

</comment></comment></comment></comment><comment><USER7> This is such a clean mental model that I was skeptical. I started scrutinizing it and found myself thinking about how it omits some deployment choices. I realized that this is a good thing, because the development and deployment choices have one big difference: development choices require rewriting when you change them. [http://benatkin.com/2013/01/14/steve-klabnik-on-rails- stacks...](http://benatkin.com/2013/01/14/steve-klabnik-on-rails-stacks/)

Thanks for this article, Steve.

<comment><AUTHOR> > This is such a clean mental model that I was skeptical.

This is a great compliment, thank you.

I mostly left deployment out because that's not part of Rails' domain: Rack lets us not care about that when building things.

<comment><USER7> I think it was a good choice to include PostgreSQL even though you can make an app DB-agnostic with rails. It's one of the defining differences between the stacks. I would really like to switch to PostgreSQL on a project I'm working on for future development even though MySQL is working fine now, and this makes me feel more confident about bringing it up to my team.

</comment></comment></comment><comment><USER22> I could not agree more. The defaults are there for a reason. There are brilliant people out there building awesome software with those defaults.

When teaching rails, I always tell people to get familiar with the defaults first then try the alternatives and make an informed decision to switch (if at all necessary).

</comment><comment><USER23> Coming from a web development background with experience using MVC in Java and Python, I found Michael's Rails Tutorial was basically all I needed to get started, even though I only came to Rails around the time of 3.0. I'm personally really happy to have skipped over ERB entirely and gone straight to HAML. But if I were teaching a web dev newbie, I might use ERB, since it still looks like HTML. Better to keep a few things familiar while someone is learning.

Perhaps Michael's book fills this space, but there may be an opportunity to write an e-book on the Prime Stack, or at least fill in some things the Rails Tutorial leaves out.

</comment><comment><USER24> As a fairly new programmer (< 1 year), I think the best thing for a beginner to do is to just pick a route and go with it. At the end of the day, both stack are going to have a lot of similarities. It all comes down to personal preference which will be determined after some time.

I started learning testing using rspec. Now I'm starting a new job where they use test unit for testing. The transition has not been too difficult because the difference between the two are too crazy.

If you pick one route and learn the basics, you shouldn't have too much trouble switching over to the other.

</comment><comment><USER25> This is a good post showing me once again how Rails evolved. I am also using rather the so called prime stack and I am wondering that the prime stack is not the default stack. For me it's total obvious to use HAML over ERB and Postgres over MySQL and I don't get why these choices aren't recommended by being default. Even CoffeeScript which has a wide acceptance and adoption is something where no clear opinion arose if it should be in the default stack or not. It offers many benefits but can bring also some heavy implications to your web app (I don't want to start a discussion about CoffeeScript here).

However, I think that Rails is not a good start for beginners in web development. On the one hand it's guiding you very well through its strick conventions and teaching you very good structuring your app (MVC- and OO-wise) but on the other hand all those abstractions and magic make you dumber. Without a big framework like Rails you try to think yourself how to solve a problem like getting the data from A to B. With Rails instead you just have to follow the respective Rails convention and voila you are ready to go. Finally, you learn Rails design patterns and best practices (or conventions) without understanding why you are doing this. And since the default stack is by far not the recommended stack makes it even worse. Because the newbie is in the beginning too afraid to leave the default track. Giving him the option "to just remove one line" to get to his preferred stack is the wrong answer because if there's a default stack people in particular the beginners assume that this must be the right way to do stuff and spent too much time fiddling around with ERB, MySQL, CoffeeScript, etc. Instead it would be better to offer a modular approach like Express, Sinatra, Web.py. I know that I can have the same modularity with Rails too but a beginner gets another message and Rails also wasn't meant being a full stack framework where -- we remember -- "convention is always over configuration" and thus also over modularity.

And even for advanced programmers I believe that Rails' time is over: the monolithic approach is so 2005 and I realize nowadays that I just want to start quickly something without an ORM, Coffee, etc. and decide later if I add those amenities.

Maybe we are facing a new generation of web development where full stack frameworks have no space anymore and David should rethink his Rails approach.

<comment><USER26> "all those abstractions and magic make you dumber"

It was the opposite for me. I had been doing java and php web dev for a few years before rails was created. The first time I used rails (before the 1.0 release), all those abstractions were a revelation. I realized, oh, I've never seen software structured this well before, and it immediately expanded my understanding of how code should be structured.

"the monolithic approach is so 2005 and I realize nowadays that I just want to start quickly something without an ORM, Coffee, etc. and decide later if I add those amenities"

Software isn't fashion. First, in rails you can start quickly and not use an ORM or coffee. I've written a whole lot of web apps in ruby over the years. Many in rails and many in sinatra. In my experience, most of the times I used sinatra I eventually wished I had just used rails because I nearly always wanted many of the rails features over time and putting all the pieces together myself was not the best use of my time. There has only been one case where a rails app I wrote should have been a sinatra app.

<comment><USER25> Regarding your first point: but you weren't a beginner anymore when you discovered Rails. You knew before how to control a raw DB without an ORM, you understood the basic structure or components of a webapp. And I still believe that those abstractions are also for a pro too heavy, hiding too much away, making web apps unnecessary complex.

"First, in rails you can start quickly and not use an ORM or coffee."

But a beginner can't and even for advanced people I wouldn't call the rampup time for a Rails app "quickly" anymore, those times are gone for a long time.

"I used sinatra I eventually wished I had just used rails"

Maybe you should give Express/Node a try -- the ecosystem paired with Node's modularity makes me much faster than with Rails and maybe you realize how slow you have been Rails, before.

</comment></comment></comment><comment><USER27> The prime stack is going to have some real problems as Rails 4 goes threadsafe by default, as haml isn't threadsafe. I guess this won't be a problem for those on process-based servers, but it's going to be an issue for those embracing multi-threaded app servers.

<comment><USER28> > ...haml isn't threadsafe.

Could you elaborate on this, please?

<comment><USER27> It appears to swap out $stderr with a StringIO and StringIO isn't threadsafe and then doesn't wrap it in a lock. It's been tripping up people in the #jruby channel.

This is a gist from one earlier today: <https://gist.github.com/be34c0a5666db0c83629>

</comment></comment></comment><comment><USER29> the rails community loves to introduce a dsl for every aspect. I couldn't agree more in that, for a newcomer to learn ruby, and the rails framework.. in some stacks they now have to learn haml, sass, coffeescript, and rspec.

<comment><USER4> Probably why I haven't delved into RSpec yet.

"it should send message to owner and shave whiskers from monkey. also, make my a latte."

That DSL seems like a _bit_ much and I don't feel comfortable letting it do black magic things behings my back.

</comment></comment><comment><USER30> Which stack is better for more complex user interfaces?

We have a dashboard app that must integrate data from several models into a single display that allow users manipulate the parameters to each specific model independently.

</comment><comment><USER31> The vast majority of rails positions out there seem to prefer the Prime stack. If I'm looking to make a career out of working in rails, then that's what I'm going to start with.

</comment><comment><USER32> Sounds a lot like ramaze or sinatra where you can BYO ORM, testing, layout, etc...

</comment><comment><USER33> my rails stack:

\- erb for view templates \- postgresql for database \- rspec/cucumber for testing \- skinny models, controllers, and a service layer

<comment><USER34> Out of curiosity, why do you like rspec over minitest/minispec?</comment></comment>


European Parliament votes to grant Snowden protection from US - <AUTHOR> http://www.theregister.co.uk/2015/10/29/snowden_amnesty_europe_parliament/?mt=1446141664945 <comment><USER2> [https://news.ycombinator.com/item?id=10471172](https://news.ycombinator.com/item?id=10471172)</comment>


Ask HN: Agency won't pay; site live. Copyright? - <AUTHOR>

I was hired by an agency to work on a project for their client. Everyone is happy with my work on the record and the site is live and operational.<p>However I have gotten the ultimate runaround as far as getting paid for any of my work. At this point, I am seriously considering getting a lawyer. Meanwhile, does anyone know if I may have a legit claim to request the agency, the main client and the host to pull down the site because significant portions of it(60-80%) are operational only because of my code or fixes.  The signed contract says nothing about copyright transfer though I've heard by default your work belongs to you until you explicitly transfer rights. <comment><USER2> I'd go to a lawyer. If you have a signed contract and can prove that they agreed to pay, you can win in court. But firstly, if you haven't already, send a cease and desist letter to them, mentioning the contract and that you will take the matter to court if they do not cooperate. I've been in this kind of trouble before and a C&D usually does the trick (as companies are intimidated by lawsuits).

Also, try sending a DMCA takedown notice to the host, notifying them of your situation. They might pull the website in question.

</comment><comment><USER3> <IANAL>Depending on the amount owed and the geography, the easiest thing to do may be to file a suit in small claims court</IANAL> assuming you are in the US.

Your contract should indicate what jurisdiction's laws are applicable, have a clause for termination, and another for dispute resolution.

A retainer to be applied to final payment is something I have found helpful - doing the last bit without another check coming doesn't suck as badly as doing the whole thing and then not getting a check.

</comment><comment><USER4> _The signed contract says nothing about copyright transfer though I've heard by default your work belongs to you until you explicitly transfer rights._

Even if the contract did say something about copyright transfer (as it probably should), they don't receive those rights until they pay you. You absolutely have the right to shut them down.

IANAL, though. You should see one if it has been more than 90 days since you delivered the work.</comment>


Cxxrtl, a Yosys Simulation Back End - <AUTHOR> https://tomverbeure.github.io/2020/08/08/CXXRTL-the-New-Yosys-Simulation-Backend.html <comment><USER2> "Once the Yosys gHDL integration stabilize, CXXRTL will be the only open source simulator with mixed Verilog/VHDL language support!"

Folks, this is huge! There isn't a single commercial ASIC/SoC project that doesn't have a mix of Verilog and VHDL.

</comment><comment><AUTHOR> Yosys, Yosys Open SYnthesis Suite, is a Free Verilog Synthesis Suite.</comment>


Neutrinos can deliver not only full-on hits but also 'glancing blows' - <AUTHOR> http://www.rochester.edu/newscenter/researchers-show-neutrinos-can-deliver-not-only-full-on-hits-but-also-glancing-blows-84012/ <comment><USER2> At first I didn't get why this result was remarkable - it's just what I would expect, imagining that subatomic particles behave like tiny billiard balls. Is it because I'm not so familiar with the math that I have gotten into the habit of thinking neutrinos are so slippery that they can only be detected in head- on collisions? That seems a curiously binary approach, whereas I would have intuitively imagined that the directness of particle collisions had a Gaussian distribution.

<comment><USER3> The original title of the research article is "Measurement of Coherent Production of π± in Neutrino and Anti-Neutrino Beams on Carbon from Eν of 1.5 to 20 GeV". I think the "glancing blows" is a linkbait from the PR department.

I'm not sure, I'm mostly guessing, but this experiment is probably important to analyze low energy collisions, and see if the model derived from the high energy collisions is correct.</comment></comment>