First Library Effort to Support Tor Stops After DHS Email - <AUTHOR> https://www.propublica.org/article/library-support-anonymous-internet-browsing-effort-stops-after-dhs-email <comment><USER2> You mean someone, somewhere might do something _bad_ with it!? Whew, its a good thing we turned it off when we did!

This is just like that time I thought people should be free to say what they think, but then someone said something that hurt my feelings and made me feel bad and I realized that it wasn't such a good idea after all.

</comment><comment><USER3> Based on this post[1] I'm guessing it wasn't even an exit node (at the time.) I can better understand serving exit traffic being controversial.

> she was concerned about the service's association with criminal activities > such as pornography and drug trafficking. "That is a concern from a public > relations perspective and we wanted to get those concerns on the table,"

The city's roads, parks, public utilities, and the library's existing internet connection all probably have connections to drugs and porn -- why is this different? I guess they think those things are generally more "appropriately used" than tor?

[1] [https://libraryfreedomproject.org/torexitpilotphase1/](https://libraryfreedomproject.org/torexitpilotphase1/)</comment>


Show HN: Coronavirus Mask Usage Simulations - <AUTHOR> https://coronavirus.simrnd.com/shopping_with_masks/ <comment><AUTHOR> I built some coronavirus simulations to explore the impacts of our actions in a virtual environment - let me know what you think!

Goals of this project are to spread high quality information around and use some basic monte carlo / bayesian ideas to show the impact of individual actions on the individual.

You may also be interested in [https://coronavirus.simrnd.com/shopping_solo/](https://coronavirus.simrnd.com/shopping_solo/), an earlier simulation that explores the impact of sending out 1 person to shop vs 2 per household.

The simulation engine is written in Rust at [https://github.com/jinpan/covid- simulations](https://github.com/jinpan/covid-simulations), which is compiled to WASM to run on the browser.</comment>


Top 10 Incredible Self Surgeries [2008] - <AUTHOR> http://listverse.com/2008/12/09/top-10-incredible-self-surgeries/

<comment><AUTHOR> This does not look like a highly credible source but it is referenced in Wikipedia so I assume most of those must be true

<http://en.wikipedia.org/wiki/Self-surgery#External_links></comment>


Ask HN: How much shall we sell our site for? - <AUTHOR>

Hi guys,
We have a site that pulls in next to no traffic. However, we've built up 18 months worth of excellent content, have 3000 people registered to the site who receive emails daily and we have a few customers who pay us money each month via our get your own template service (we sell a basic template of our site to users who can then have their own website, we host it for them).
The site is popular amongst the people who do visit it each day (less than 1000). We've been featured by Mashable, BBC and Techcrunch and have around about 500 Twitter users.
Problem is we've reached a point where we can't spend the time updating the site any longer. Someone has emailed us saying they're interested in buying the site and wondered how much we'd sell it for.
We've spent 18 months curating content and developing the site into what we consider a nice product. If someone spent some proper time on it, and focused on SEO, then we think it could do ok. Is a price of $1000-$5000 fair or is that way too much? We would like some money in return for our efforts these last 18 months but appreciate it will be a small amount.
Any advice you can give would be great! Thanks! <comment><USER2> Don't sell it. I might want to partner with you. email@example.com.</comment>


A/A Testing: How I increased conversions 300% by doing absolutely nothing - <AUTHOR> http://kadavy.net/blog/posts/aa-testing/

<comment><USER2> Which is why scientific tests have a placebo option.

Very loosely, what hypothesis testing is telling you is whether your results are so aberrant that they can't just be explained by model variance (coins flipped at random). The hypothesis that can't really be tested is whether your model explain most of the variance in observed data.

If I take a random sample of people, ask them whether they're male or female and what's their yearly earnings, I'll find statistically significant differences in averages; however, that will explain only a very small portion of the total variance in wages, given that these also depend on education, skills, experience...

It could be that the main source of variance in the poster's experiment is the time of the day emails are sent. How would he know? When doing crude A/B testing one hopes that all the things in the world one _isn't_ controlling (is it raining? have local sports team won trophies?) are uncorrelated with the control variable. But here it might not, there might be something very different between the batches he doesn't know about.

And he's proud of that!

</comment><comment><USER3> He makes some great arguments. Especially for the solopreneur (like me), making maximum use of time and energy available to me during the day is critical. There is risk in spending time on A/B testing, with the results of much work put towards this coming back "Inconclusive".

I could see extreme cases where you need to test a major area of the business, testing an entire market segment, etc...but then you could argue just pick up the damn phone and call people in that market segment.</comment>


FinTech Companies vs. Retail Banks, Round 1 - <AUTHOR> http://blog.getcrane.com/5-fintech-companies-to-disrupt-retail-banks

<comment><USER2> Google Banks is something that scares me... A LOT. I use almost all of their services because I love them, but I don't think that I would go for a bank account as well.

<comment><AUTHOR> Still, I don't think it's really fair to compare Google or Amazon with startus like Transferwise or GoCardless</comment></comment>


Groups.io - <AUTHOR> http://www.groups.io/

<comment><AUTHOR> A project I created in my free time.

I'd appreciate your feedback please.</comment>


Non-Posix File Systems - <AUTHOR> https://weinholt.se/articles/non-posix-filesystems/ <comment><USER2> I've wanted somewhat different file system semantics, but close to the POSIX model:

\- Unit files. The unit of consistency is the entire file. Files are opened for writing, written, and closed. Then then become openable by other programs. Overwriting a file replaces the file as a unit; other readers see the old file until the writer closes and the reader reopens. This is the default and the case for most files. On a crash, the file reverts to the previous good file, if any. Can be memory-mapped as read only. File replacement can be done now through non-portable renaming gyrations. It should just work.

\- Log files. Append-only mode, enforced. Can't seek back and overwrite. On a crash, the file recovers to some recent good write, with a correct end of file position. It does not tail off into junk.

\- Temp files. Not persistent over restarts. Not backed up. Can be memory- mapped as read/write. On a crash, disappears.

\- Managed files. These are for databases. Async I/O available. May have additional locking functions. Separate completion returns for "accepted data" (caller can reuse write buffer) and "committed data" (safely stored), so the database knows when the data has been safely stored. Can be memory-mapped as read/write. Intended for use by programs which are very aware of the file system semantics. On a crash, "committed data" should be intact but data not yet committed may be lost.

<comment><USER3> > Overwriting a file replaces the file as a unit; other readers see the old > file until the writer closes and the reader reopens.

This is the semantic rename provides, and the strength of that semantic is a common complaint from many in the anti-POSIX crowd. I suspect you knew that already, but the number of syscalls would be similar in either case except that the latter file would need to be visible before the rename. Linux does provide O_TMPFILE + AT_SYMLINK_FOLLOW which provides the nearly ideal behavior. (Nearly because it still requires /proc/self/fd access, AFAIU.)

> Log files. Append-only mode, enforced

Both chflags (BSD) and chattr (Linux) provide append-only modes attached to the file/inode (instead of the file descriptor or open file table entry)[1].[2] Neither command nor their options are defined by POSIX, but _adding_ more requirements to POSIX filesystem conformance goes against the grain of prevailing sentiments.

> Temp files. Not persistent over restarts. Not backed up. Can be memory- > mapped as read/write. On a crash, disappears.

Again, the semantics of unlinking deliberately provide this, though it does make it invisible in the normal namespace. But there's a tension between leveraging the namespace for implicit semantics (Plan 9) vs adding a multitude of options and modes attached to each particular file (Windows).

It's also not uncommon for temporary filesystems like /tmp to be reformatted on boot if the backing store is persistent. That's one reason to use multiple filesystems for a Unix install.

[1] Note that O_APPEND mode is attached to the open file table entry, not the file descriptor, so the mode is inherited across dup and interprocess descriptor passing. Interestingly, on Linux /proc/self/fd (also /dev/fd, which is a symlink) has the semantics of open, not dup, so file table entry state like O_APPEND is lost; whereas on BSD /dev/fd has the semantics of dup so O_APPEND is preserved/enforced.

[2] Solaris lacks chattr and chflags, but chmod supports an append-only option.

<comment><USER4> > Both chflags (BSD) and chattr (Linux) provide append-only modes attached to > the file/inode (instead of the file descriptor or open file table entry)

On Linux, by default only the superuser can set the append-only flag. That severely limits its usefulness for many applications

> adding more requirements to POSIX filesystem conformance goes against the > grain of prevailing sentiments

POSIX is of declining relevance. What really matters nowadays is can you get Linux and *BSD (including macOS) to agree on implementing something new. Get one to add it, and convince the others to copy it. If you can do that, then getting it added to the POSIX standard is likely to be easy.

Vendors hardly care about POSIX certification anymore. The latest version of POSIX/SUS, UNIX V7, currently has zero certified implementations. (Oracle Solaris did achieve V7 certification, but has since lost it; I don't know exactly what happened, but I suspect Oracle refused to pay the certification renewal fees.)

<comment><USER3> > On Linux, by default only the superuser can set the append-only flag. That > severely limits its usefulness for many applications

Ah, good point.

> Get one to add it, and convince the others to copy it. If you can do that, > then getting it added to the POSIX standard is likely to be easy.

In actuality it usually works in reverse: Red Hat (now IBM), which has the most dominate presence on the committee, convinces POSIX to add or modify something, and then everybody else adopts it. Examples: asprintf, fmemopen, stpcpy, vdprintf. I can't really think of an example that worked the other way around, though there may be some in the next specification.

The fact that nobody is certified to V7 is beside the point. Nobody is certified to the latest HTML5 standard, either, AFAIK. The point is to provide a shared target. Few people want to copy Linux or glibc because the semantics are invariably underspecified and in part accidental, and people would prefer to avoid those aspects even if they have no other choice but to nominally adopt the interface. Standardization provides a chance to clarify behavior and to fix the bounds of what a portable program can expect long term. If I have to support epoll + kqueue in perpetuity (and I assume I do), I'll structure my program differently.[1] However, if I want to use pselect (or the forthcoming ppoll), I'll target the POSIX-defined semantics, provide a best effort wrapper (or none at all), and tell users on slower evolving platforms to complain to their vendor.

The Linux kernel strives for strong ABI backward compatibility, but it hardly has a perfect track record in that regard (e.g. sysctl(2)), and the future is even more unclear given the various directions it's being pulled. Even POSIX can change course, but it does so more methodically than with a Github code search. And while Linux doesn't make promises regarding POSIX compliance, it's less likely to break POSIX semantics than its own semantics, ceteris paribus. Whether that's because kernel developers value POSIX compliance, or merely because POSIX-vetted semantics are narrower and less accidental is irrelevant.

[1] Also, I'll take the bet that epoll is never standardized, precisely because of its accidental and sometimes very undesirable semantics as compared to kqueue. At best we'll get a greatest common denominator interface that can be built around both--or possibly taking into consideration Solaris ports.

<comment><USER4> > In actuality it usually works in reverse: Red Hat (now IBM), which has the > most dominate presence on the committee, convinces POSIX to add or modify > something, and then everybody else adopts it. Examples: asprintf, fmemopen, > stpcpy, vdprintf.

I'm not convinced your timeframe is right. stpcpy was added to FreeBSD in 2001, didn't officially become part of POSIX until 2008. Red Hat didn't invent stpcpy either; it was invented on the Amiga in the 1980s, and the GNU project adopted it from there and then Linux acquired it from the GNU project. I think if we studied the history of the other functions you mention, we'd also find that their formal addition to POSIX wasn't the primary cause of their spread, just a formal recognition of an existing _de facto_ reality.

<comment><USER3> My Ubuntu LTS man page says:

> This function was added to POSIX.1-2008. Before that, it was not part of the > C or POSIX.1 standards, nor customary on UNIX systems. It first appeared at > least as early as 1986, in the Lattice C AmigaDOS compiler, then in the GNU > fileutils and GNU textutils in 1989, and in the GNU C library by 1992. It is > also present on the BSDs.

(See also [https://man7.org/linux/man- pages/man3/stpcpy.3.html](https://man7.org/linux/man- pages/man3/stpcpy.3.html))

OpenBSD didn't adopt stpcpy until 5.1, circa 2012 ([https://man.openbsd.org/stpcpy](https://man.openbsd.org/stpcpy)) and NetBSD until 6.0, also circa 2012 ([https://man.netbsd.org/stpcpy.3](https://man.netbsd.org/stpcpy.3)). In that time frame there was a flurry of activity in both projects regarding POSIX compliance.

My experience with the others was similar, though not uniformly. Support on OpenBSD, NetBSD, macOS, and AIX typically post dated their addition to POSIX. Whether they would have been added independent of POSIX I can't say, but there are plenty of GNU extensions that remain unsupported, and some, like strerror_r (specifically the return type and behavior on error), that likely will never be.

While not specifically on point, I think it's noteworthy that the proposal to add stpcpy to C2X was made by Martin Sebor, a Red Hat employee: [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2352.htm](http://www.open- std.org/jtc1/sc22/wg14/www/docs/n2352.htm) Red Hat doesn't share the seemingly pervasive cynicism regarding standardization. Precisely what motivates that, I'm hesitant to speculate. Like most things I'm sure there are mixed motives.

<comment><USER4> macOS's man page says "The stpcpy() function first appeared in FreeBSD 4.4". I believe FreeBSD 4.4 was released in September 2001. So that's approximately 7 years before it was added to POSIX. Given that timeframe, it seems unlikely that POSIX has much to do with its presence in FreeBSD. A much more likely explanation is to ease porting of GNU projects (and software developed on Linux) to FreeBSD.

From checking opensource.apple.com, I conclude that OS X added it in 10.3, released in 2003, so that's around 5 years before POSIX 2008. Again, given the timeframe, it seems hard to argue that POSIX triggered Apple's action here.

Given Linux, FreeBSD and Darwin all already supported it, I wonder to what extent NetBSD/OpenBSD's decision was motivated by formal POSIX conformance versus improving compatibility with Linux/FreeBSD/Apple. It is hard to say, but I think the later was likely just as important as the former, and given the importance of the later, they might still have added it even if it had never formally made it into POSIX.

<comment><USER3> > Given Linux, FreeBSD and Darwin all already supported it, I wonder to what > extent NetBSD/OpenBSD's decision was motivated by formal POSIX conformance > versus improving compatibility with Linux/FreeBSD/Apple. It is hard to say, > but I think the later was likely just as important as the former, and given > the importance of the later, they might still have added it even if it had > never formally made it into POSIX.

One of the benefits of standardization is, "here is a definitive list of things that need to be added". With rare exception (e.g. async I/O), there's no hand-wringing regarding whether a POSIX interface should be added. Search for the keyword "POSIX" among the OpenBSD 5.1 (circa 2012) changes at [https://www.openbsd.org/plus51.html](https://www.openbsd.org/plus51.html) Now search for Linux. For whatever reason stpcpy isn't listed (a tweak is listed in plus52.html), but you'll see where the emphasis lay.

Linux POSIX conformance is incredibly good, particularly at the libc level notwithstanding lack of formal certification[1], so invariably it's tough to say, absent direct confirmation, what was on people's minds. But at least on the OpenBSD mailing-lists, more often than not the explicit reason is POSIX compliance. And I get the same impression from reading NetBSD changelogs. FreeBSD is unique because they've been far more proactive with not only adding POSIX interfaces, but also adding their own extensions. And historically they were a bigger player and in many ways the heir to the "BSD" mantle; certainly more so than NetBSD. But pre-existing support doesn't negate my point (see plus51.html for evidence concerning the immediate motive behind adding stpcpy), nor does the fact that an interface supported by multiple vendors is more likely to be adopted by POSIX. I could likewise dredge up some SysV and other extensions that weren't supported in Linux or glibc until they were adopted by POSIX.

Which isn't to say platforms don't adopt Linux interfaces (whether or not they originated with Linux) with an eye toward Linux compatibility; of course they do, and do so increasingly. For example, I know that OpenBSD refactored their getpeerid interface as a wrapper around newly added getsockopt+SO_PEERCRED support, which I've always assumed was a nod to Linux compatibility, or at least an admission of the obscurity of getpeereid. OpenBSD also adopted MSG_NOSIGNAL (POSIX, SysV'ish, Linux) instead of the SO_NOSIGPIPE that already existed on FreeBSD, macOS, and NetBSD (likewise for F_SETNOSIGPIPE and O_NOSIGPIPE supported by macOS and NetBSD), which goes to show that OpenBSD doesn't merely add whatever interface might marginally aid portability.[2] MSG_NOSIGNAL was a no-brainer as compared to the alternatives, and that would have been true regardless of whether Linux supported MSG_NOSIGNAL. If you want to add an interface, the default answer is "yes" if it's POSIX; if it's not POSIX the default answer is "tell me more". POSIX is self-justifying. That difference in friction might seem de minimis, but ask anyone who has maintained or tried to contribute to a large open source project. The ability to appeal to a standard model which already has buy-in by the project is a major convenience in terms of everybody being on the same page.[3] In that way it can drive behavior unintentionally, which isn't an accident as it pertains to the the salience of a formal standard. Of course, Linux is a de facto target for most projects, and one of far more concern than nominal POSIX conformance, but that doesn't diminish the value of POSIX targeting, and IME neither has it diminished the interest in POSIX conformance among the people for whom it actually matters--those interested in portability, which tend to be disjointed from the set of people for whom POSIX is a dirty word.

[1] IME it's better than macOS even though macOS is UNIX03 certified. glibc and musl take POSIX very seriously, both the letter and the spirit. Developers from both projects actively file tickets on [https://austingroupbugs.net](https://austingroupbugs.net) to remediate errors and omissions in the text, and problems with actual semantics, explicit and accidental. Various BSD developers are also active there, but I get the sense of a pecking order, if only because of Red Hat's large presence (literally and figuratively).

[2] Contrast that with kqueue. FreeBSD, macOS, NetBSD, and OpenBSD kernels have diverged significantly since kqueue was adopted. You can't copy+paste kqueue-related kernel code across them. But they still look to each other for prior art when it comes to filling gaps or extending the behavior of kqueue, and uniformity is given significant weight. (Especially across *BSD. macOS extensions don't always make the most sense, like with macOS's poorly considered EV_OOBAND. See [https://sandstorm.io/news/2015-04-08-osx-security- bug](https://sandstorm.io/news/2015-04-08-osx-security-bug)).

[3] "Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights." [https://diff.substack.com/p/working-in-public-and-the- econom...](https://diff.substack.com/p/working-in-public-and-the-economics) Fights over whether or not to support POSIX are relatively rare. The ones that happen are infamous because they're the exception.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> Article describes Multics' ability to have a file's directory entry on disk but its contents on tape, so trying to access its contents will cause it to be retrieved from tape, and then asks "Is something like this offered on any POSIX-compatible file system?"

What the article is describing is basically just HSM (Hierarchical Storage Management), which is a commercially available technology – e.g. Sun/Oracle SAM-QFS on Solaris, IBM Tivoli Storage Manager on AIX, DFSMShsm on z/OS.

Windows NTFS also supports HSM, although the core NTFS itself only provides features necessary to implement HSM (such as FILE_ATTRIBUTE_OFFLINE and reparse points), and you need an add-on to Windows to actually use those features to produce a full HSM solution. (Actually Windows itself used to include such a solution, Remote Storage Service, but Microsoft removed it in Windows Server 2008 onwards; but the underlying functionality is still there in NTFS, and available for third party HSM implementations to exploit.)

<comment><USER5> You could also implement this pretty easily in FUSE: if the dirent is present on the underlying (ext or whatever) filesystem, just forward the operations, otherwise leave the syscall blocked and hunt down the relevant backup. I don't know that anyone's actually written that, though.

<comment><USER6> Nothing about this is "easily" once you work through the edge cases for performance and reliability. The only places which need HSM have enough data volume and range of applications to stress any simple solution (e.g. with the approach you outlined: what happens when someone runs find on that volume?). One of the more interesting challenges is how to deal with not having quite enough fast storage to batch the slow storage. Your system can appear to work well with one test workload and then fail miserably when two people start running different tasks at the same time.

After a couple decades of this, I generally think this class of software is a mistake. Any time you misrepresent one class of storage as another it inevitably leads to very complex software which is still pretty fragile and confuses its users on a regular basis, and the cost savings never deliver to the hoped-for degree.

<comment><USER5> Well obviously the performance is going to be terrible, but it's probably better than the zero performance you get if you block everything while waiting for the system to fully restore from backup.

> what happens when someone runs find on that volume?

It stalls until all the directories are restored? And hopefully pushes those directories to the front of the to-be-restored-from-backup queue, but even without that it's still better than not being able to run _any_ operations on that volume.

<comment><USER6> It can be worse than zero: your tape drive get hit with lots of small file requests, running much slower than it would be to stream a restore of a large batch containing all of the files you need, and causing increased failure rates on the hardware and media because tape drives are designed to stream, not seek. I've had to explain this to multiple HSM admin teams who were trying to save a few bucks on staging HDD capacity and surprised to see it taking over a month to restore a terabyte of data (not joking - and that was with multiple drives!) and hardware failing at like 5x the manufacturer's estimates.

What you're trying to do is akin to saying you can write an interface layer to make a railroad look like Uber: at some point the fundamental differences between the architectures are too much to paper over. The situation has improved now that the major operating systems have offline file support so you can make it more obvious that some files are not instantly available but you still need all of your client software to handle that gracefully.

</comment></comment></comment></comment></comment><comment><USER7> Surprised no mention of plan9's FS. It always seemed like the core innovation in plan9.

Basically, everything is a file. But to a ridiculous extent, far beyond what you'd normally think of as files. It's been years since I looked into it though, so maybe I'm misremembering.

Designing it that way has lots of advantages. For example, you can connect computers together via networks using the equivalent of `cat`. (And yes, we have netcat, but it's not quite the same thing as having the abstraction built into the OS.)

<comment><USER8> How did Plan 9 allow its APIs to evolve? For example, reading /dev/mouse returns records that are exactly 49 bytes, in text format [1]; how did they add new fields without breaking every app?

1: [http://man.cat-v.org/plan_9/3/mouse](http://man.cat-v.org/plan_9/3/mouse)

<comment><USER9> As a sibling notes, they could have just added a new file while supporting the old format, but they had some leeway in the format itself: the buttons value only uses three bits.

Had they been a little more clever and used a delimited format like S-expressions, they could have simply specified that each mouse event would generate one S-expression, and clients could have read one expression at a time.

</comment></comment></comment><comment><USER10> This is incidentally why the Common Lisp file I/O functions are a bit more complicated than you might expect. You can ignore most of it if you assume something vaguely POSIX-like, but if you want to be portable to e.g. both Unix and VMS (as was once desirable), there are functions like _make-pathname_ that build a representation of a file location from up to 6 parameters (host, device, directory, name, type, and version). The 3 examples in the docs are interesting: [http://clhs.lisp.se/Body/f_mk_pn.htm](http://clhs.lisp.se/Body/f_mk_pn.htm)

<comment><USER11> But do they go as far as the features noted in the Hydra file system?

<comment><USER12> No it was a tagged architecture but not a capability system. In fact everything ran in a single address space.

</comment></comment></comment><comment><USER13> This is a good read. I believe that Steve Bourne (of Bourne Shell fame) implemented the file system in UNIX at Bell Labs but I may be mis-remembering that. He was also a big Multics fan.

What is unsaid in this article is that nearly all file systems that are in widespread use today, started when "disk space" was a constrained resource. It is a very reasonable thing to ask, "now that stable storage space is much more plentiful, how might we design systems that are better than the current ones?"

The ability to scavenge blocks to re-create state is a good example of that.

One of the cool things about WAFL (the Write Anywhere File Layout) system that NetApp used (uses?) was that it's very design made snapshots 'trivial' since every write to disk was to un-allocated blocks. What that meant in practice was that the file system on disk was _always_ sane. This was what let you pull the power from the box at any time, and assuming its non-volatile RAM was still available, it could always recover. Something that you could do with Intel Cross Point memory and a bunch of disks.

Microsoft research built a number of interesting file systems, some more successful than others, which incorporated many of the ideas from Multics and other OSes.

All in all, its a fun place to experiment.

<comment><USER14> WAFL trick is COW, which had been popularised massively by ZFS

<comment><USER13> As you have observed they have an identical design philosophy.

There is a not so funny story there where a person interned at NetApp and then went to work at Sun and re-implemented the patented technology as ZFS.

</comment></comment></comment><comment><USER15> I was expecting another article about the current crop of _less than_ POSIX filesystems, but I was pleasantly surprised to find it was about older systems with features _absent_ in POSIX. Very interesting stuff. Kudos. I wonder if I can find some information about MTS's filesystem, which also had some neat features especially with respect to access control (PKEYs). Might be a worthwhile addition.

<comment><USER16> The whole point of the Unix FS was that the developers felt the mainframe approach (~"files are actually sorta like databases") as to complex and heavyweight.

<comment><USER15> What the OP should teach us is that there wasn't any one mainframe approach. There were many approaches, each involving many components. The process of standardizing what we now know as POSIX involved pruning a lot of unnecessary pieces, but it also inevitably involved leaving out some features that might actually have been useful. Some of them ( _ahem_ ACLs) even had to be added back in later versions of POSIX. Just as we should never stop looking for new ideas that can make our lives as programmers and users easier, we should also never forget old ideas whose time might well have come back around. It has happened too many times for the possibility to be ignored except by fools.

<comment><USER17> Engineering has always been a tug-of-war between parsimony and completeness. The pendulum is constantly swinging.

</comment></comment></comment></comment><comment><USER18> I was fortunate enough to be working for Basho and attended the RICON where mrb gave his distributed systems archaeology talk. It really highlighted for me how so many important ideas are captured in historical whitepapers and often forgotten today.

[https://speakerdeck.com/mrb/distributed-systems- archaeology](https://speakerdeck.com/mrb/distributed-systems-archaeology)

Regrettably many RICON talks were lost when Basho went out of business, but someone rescued this one. Thanks Alex Ott!

[https://youtu.be/om_mAaM5sL8](https://youtu.be/om_mAaM5sL8)

</comment><comment><USER19> Acorn's "ADFS", as used in RISC OS, uses "." as the directory separator. Fully qualified paths look like this:

fs::drive_id.$.directory.directory.filename

Where "$" means "root directory". (On network filesystems, you can also use "&" which means "home directory".)

The top level identifier is the filesystem type, usually "adfs", which is a slightly unusual way of doing it.

Bringing in files from other systems, which invariably have filename extensions, involves converting the . to a /, so you end up with filenames like "readme/txt". ADFS stores the file type not as a filename extension, but as a three-character hex ID in the filesystem instead. (Text, for example, is FFF.)

<comment><USER20> On the BBC Micro-era pre-hierarchial DFS, there was a single level of single character directories, so files were called things like "d.file". $ was the default directory rather than the root.

The Acorn/Norcroft ARM C compiler used c and h directories which effectively swapped the file extension around, so sources were named like c.main, and #include would try swapping name and extension for compatibility. It was about as Unix-flavoured as was possible on the Archimedes...

</comment></comment><comment><USER12> Having used both Multics and the Alto, I can add a few points:

Multics as implemented used a slightly different syntax, such as > for path separation.

Segments were not file descriptors but were intended to be what might today be called blocks. The original idea was that the entire memory would essentially be a single address space, with segments being blocks of memory that might be in core, on disk, or on tape (called very slow storage if I remember correctly but it's been decades). Security was at the segment level, so you could for example have (in posix parlance) an suid shared library that an ordinary program could, with appropriate authentication and permissions, call into in a controlled manner. Multics' permission structure was more fine grained than the binary of suid. You can see how the backup system kind of falls out of this automatically. I trust some multician will step up and correct any memory-corruption-based thinkos in the above.

Of course reality didn't quite match the dream and Multics was cancelled before some of that research could be completed. But if you look at the x86 segment registers they could implement something like that. I think this was also in the intel iapx-430 but fortunately even the name of that ancient dead processor is hazy in my mind.

As for the alto filesystem and its descendants: the labels don't have to be next to the blocks they describe. After all Unix filesystems have multiple copies of their basic breadcrumbs at least. There's certainly plenty of room for these in modern storage systems; every modern drive, whether spinning or ssd, does a small amount of this in block remapping and wear leveling.

</comment><comment><USER21> Was surprised not to see the VAX/VMS filesystem on the list. It had both stream and record based files, versioning, and a fairly rich ACL setup.

<comment><USER22> It also allowed for amazing clustering.

I would guess there are quite a few filesystems lost in history. My personal favorite will be the Newton's Soups. A modern version with replication would be amazing.

</comment></comment><comment><USER23> FUSE allows you to experiment new (or old) features easily nowadays, too bad it isn't mentionned in the article:

[https://en.wikipedia.org/wiki/Filesystem_in_Userspace](https://en.wikipedia.org/wiki/Filesystem_in_Userspace)

I use borg mount to access my backups for example.

<comment><USER24> FUSE effectively provides a POSIX-like interface to arbitrary code, whereas the author is lamenting that these features weren't built into Unix/POSIX-like systems to make them widely available in the first place.

The "problem" with modern POSIXish systems is that the definition of what is "POSIX" seems to be set in stone. All the various Unix-likes offer POSIX compatibility (or aim toward it) while new features that extend capability end up being implemented in completely different ways across different systems.

So for example while Linux has inotify (arguably an implementation of the filesystem traps that Multics had), SGI had FAM, FreeBSD has kqueue, MacOS has FSEvents, and they're all incompatible with each other... a nightmare for developers of portable applications.

<comment><USER25> >a nightmare for developers of portable applications.

man 2 fstat.

<comment><USER26> fstat is not a mechanism for being notified when a file changes.

<comment><USER25> I've just shown you another example on incompatibility.

</comment></comment></comment></comment></comment><comment><USER27> >"The very first hierarchical file system was developed for Multics. It is described in the paper A General-Purpose File System For Secondary Storage (1965) by Robert C. Daley and Peter G. Neumann. There are several things that I find astounding about this paper:

There were apparently no hierarchical file systems before Multics. The references do no cite any previous work on this and I haven't found any."

(PDS: As an amateur computer historian, I'd be interested in this myself, if there existed any hierarchical file system before Multics, or if one was conceived in any academic paper before the one cited...)

[...]

>"Directory entries that point to secondary storage. _This is a game changer for file system management._ More on this below."

(PDS: Which, to this day, is one of the great abstractions, one of the _great ideas_ , in computing!)

</comment><comment><USER28> For anybody who has the desire and opportunity to interact with something currently in production and truly alien-feeling, I warmly suggest IBM's AS/400 (now iSeries) OS/400's filesystem. Library versus folders, logical versus physical files, integrated DB2 database is one of the many, many head- scratchers you'll encounter until you suddenly "_get it_".

</comment><comment><USER29> Portability was important and so more complex capabilities were not sufficiently used to survive and spread. I wonder how the similar struggle ends for advanced cloud features.

</comment><comment><USER30> And this guy have not heard about IBM OS/400 and VMS yet :)

</comment><comment><USER31> Strange that BeFS/BeOS is not on this list.

<comment><USER32> A good read: [https://arstechnica.com/information- technology/2018/07/the-b...](https://arstechnica.com/information- technology/2018/07/the-beos-filesystem/)

</comment></comment><comment><USER33> Anyone remembers Novel NSS? Even when it got ported to Linux as part of Open Enterprise Server it lacked a lot of POSIX features. The ACLs were the weirdest part since they had to be configured in eDirectory's LDAP console.

</comment><comment><USER34> What I really want that isn't there in POSIX is not directly a file system feature but something more general: I really want some sort of "middleware- system" to intercept all sorts of events (like file system access, binary execution, network or device access etc.). There should be multiple intercepting programs that handle one or more events each and can decide to block or pass the event to the next interceptor. They could also log or modify parameters of the event (like redirect a file read or wrap a binary that's about to be executed in another program like script or torsocks).

You could even use this system to implement some Unix features as interceptors: Shebangs and even file system permissions could be handled this way. You could also implement containers with this or provide some kind of "switchboard" UI akin to uMatrix for letting the user decide on permissions.

<comment><USER35> Have a look at the Genode operating system (genode.org), I think you'll like it!

</comment></comment><comment><USER36> No mention of the immutable content addressable hash file system presented in the Artifacts System[]. One of the benefits of a system like this is that you can have multiple versions of a library coexisting without conflict with your requirements system. Each program can reference a different hash, duplicates are easily made unnecessary because they resolve to the same hash, etc.

[][https://apps.dtic.mil/dtic/tr/fulltext/u2/a276589.pdf](https://apps.dtic.mil/dtic/tr/fulltext/u2/a276589.pdf)

<comment><USER37> Sounds like having your libraries stored in git repos and then having your programs point to the commit they want to use. Something like this would solve headaches that there are innumerable tools for. A much more elegant solution for the problems things like pyenv or nix are attempting to solve.

<comment><USER36> Yes, exactly, except for local first, and for all your files in your filesystem (documents, libraries, program source code, etc.), and collaborative.

</comment></comment></comment><comment><USER38> It would be interesting if a "file type" existed to provide these more complex operations, and if those could also be bound to a daemon running with provided parameters.

This would allow for a filesystem name linked to a database API / any other daemon or program.

I also love the TRAP (related to above) and both directory operations. Quotas can sort of fulfill the space limits thing (but I've never bothered using such a system and haven't been on a system that did). Append Only directories are a far harder beast to slay, but would very nicely fulfill many queue submission systems.

</comment><comment><USER39> _> Why can your browser run sudo? ...Suppose only your SSH client had the operation required to use your SSH keys._

Perhaps I'm missing something, but why could a malicious application (say, Chrome in the context of a browser running sudo) not also include the capability to access the file system with impunity?

It seems that Hydra simply turns the technical problem of managing filesystem protections into a political one, of auditing the applications we use; which may have been practical in the 80's, but is now demonstrably a failed method of protecting user data.

</comment><comment><USER40> Interesting POSIX history. It used to come down to Windows/Mac and POSIX, but for the past 20 or so years we've been seeing new filesystem styles emerge, which blend cloud and on-device storage. Navigating the iOS file save menu is a good example. 3rd party apps like Google Drive and DropBox hook into the OS and show up in the list. I think this is probably the way things are headed, and POSIX and the "Windows/DOS/Classic Mac" style will both fade away.

<comment><USER41> Menus ≠ filesystems.

POSIX will last forever because it's simple, standard, solid, portable and fairly flexible (see FUSE). DOS will last forever because inertia is the only reason Windows still exists, and MS knows this and prioritizes backwards compatibility, eg. it's still basically impossible to name a file CON on Windows 10 because of backwards compatibility.

<comment><USER42> That's a shortsighted and very programmer-centric view of what a filesystem is.

Increasingly we are seeing a bifurcation between the kind of filesystems developers use for programming (POSIX style) and the kind of "filesystems" being exposed to end users. I put the word in quotes because they are not thought of as filesystems by its traditional definition. But it's a reality that many users now think of these siloed-by-app systems as the real filesystem.

The iOS menu mentioned by GP is a great example because that's what's user facing, not the developer-facing one like /private/var/mobile/Containers/blah- blah-blah. Today even many developers won't have to deal with POSIX-style filesystems that often, since they generally write code to store structured data in a database (sqlite on mobile, more sophisticated ones on the server side) while large blobs are stored in services like S3, making the idea of a POSIX filesystem quaint.

My own prediction is that POSIX filesystems in another decade or so will be like assembly language today: it's still there, still being taught and learned, but users and a majority of developers won't need to know about it.

<comment><USER43> Casual users' confusion about the presentation of technical details is a different conversation. This one is about actual filesystems.

It may well be that end users are abstracted away from their filesystems, but you seem to assume both that 'The Cloud' is the natural end-state of systems evolution and that everyone comes along for the ride.

I don't think either of those are true.

</comment></comment></comment></comment><comment><USER44> _> When you use a file system through a library instead of going through the operating system there are some extra possibilities. You are no longer required to obey the host operating system's semantics for filenames. You get to decide if you use / or \ to separate directory components (or something else altogether)_

This is really about time in 2020 that someone (Apple, MS, Linux, FreeBSD, Plan 9 I'm looking at you) implemented this!

</comment><comment><USER45> Fascinating to see other possibilities that were out there. Were the capabilities in Hydra the inspiration for what Fuchsia OS has, or are they a long standing concept?

<comment><USER46> Hydra and Fuchsia are both operating systems that use Capability-based security. Hydra would have been one of the very earliest ones, while Fuchsia is a very new one. There have been many others in between, like KeyKOS or EROS, as well as use of capabilities in "normal" operating systems, like FreeBSD's Capsicum, or arguably even just passing file descriptors over Unix sockets with SCM_RIGHTS on any POSIX system. There have also been capability- based programming languages like E and Pony, and capability-based network protocols like CapTP or (my own) Cap'n Proto. So it's unlikely that the designers of Fuchsia directly based it on Hydra, but there was probably indirect inspiration, yes.

<comment><USER12> Capability systems have been an area of research since the 60s

</comment></comment></comment><comment><USER47> This is a great article. For anyone wondering about the current data storage stack on Unix-like systems today, I wrote a simple article that goes over it [1].

[1] [https://venam.nixers.net/blog/unix/2017/11/05/unix- filesyste...](https://venam.nixers.net/blog/unix/2017/11/05/unix- filesystem.html)

</comment><comment> GuB-42 Maybe another filesystem worth mentioning would be WinFS.

It should have been one of the major features of Windows Longhorn, which later became Vista.

Simply put, it was a relational database, with features you typically find in RDBMS like Postgres or Microsoft's own SQL Server, which took advantage of some of the work done on WinFS.

</comment><comment><USER48> All this innovation and meanwhile, when I pull out a USB drive that was not properly unmounted, I risk corrupting it to the point it becomes unusable.

</comment><comment><USER49> How did this get to be the top link on HN in under 20 minutes with 0 comments?

<comment><USER50> Comments are not a ranking factor. Per the FAQ:

> The basic algorithm divides points by a power of the time since a story was > submitted.

... So what matters is that this story was upvoted _quickly_.

<comment><USER51> Comments are actually usually a downranking factor, to try to prevent flamewar posts from staying on the front page.</comment></comment></comment>


Secret Origin of SVG - <AUTHOR> http://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG <comment><USER2> It's interesting how Microsoft have been very influential on web standards and development in some key ways. Web Outlook as the first AJAX application, and here in the early history of SVG. Yet never managed to turn that into actual technological or market leading success.

The best I can make of it is that they do have some wickedly clever engineers in there, but appalling management. While web outlook was redefining web application development practices, Hotmail was devolving into a decaying has- been of a service. Where it looks like VML could have become a key web technology, giving Microsoft a market leading position in browser support and authoring tools, instead it became a proprietary ghetto product and they were one of the last browser makers to grudgingly support the new open standard.

Great technology. Incompetent leadership.

<comment><USER3> The reason Hotmail has stagnated under Microsoft is because of the programmers, not the management. Since there aren't any interesting technical problems in it, none of the hot shot programmers want to work on it. I'm positive that inside Microsoft the view is that Hotmail is something a clueless manager saddled some unlucky programmers with.

</comment></comment><comment><USER4> This gives an idea of the frustration of watching the w3 in the 1990s and the way they behaved at the time.

Microsoft: Here's a working, fully implemented and debugged, format for doing vector graphics in a browser. How about we standardize on that?

W3C: Cool, we'll take a look at it... [overthink overthink overthink] ... OK, here's our brand new, "Standardized" way of doing vector graphics in a browser, which nobody has tried to implement and only somewhat overlaps with IE's working reference implementation.

Microsoft-hating-developers (which was understandably most of them back then): Grr!!! Microsoft, you've broken the STANDARDS again!!! M$ Sucks!

I remember this exact cycle repeating itself a half dozen times in the 90s, and it took a lot of the fun out of trying to build web apps that worked cross browser.

<comment><USER5> Nobody has tried to implement, only somewhat overlaps existing implementations, and probably contains some nontrivial set of computationally expensive or infeasible standards. (See quincunx's comment elsewhere in this discussion, for example.) Then people online complain how long it takes the browser makers to implement full compliance to, say, the latest CSS spec.

In general, the W3C has worked better than just letting random groups run rampant, but I am coming around to preferring the style where we don't call it a standard until there are at least two implementations already.

</comment></comment><comment><USER6> Am I the only one who believes that SVG is going to eat up the world in next couple of years? Quite a few applications/start-ups focusing on it lately!

<comment><USER7> From reading the spec, the problem with SVG is that it is very difficult to implement completely due to the all-encompassing rendering model, javascript integration and animation scripting. This makes it difficult to read and write, without pulling in half a browser, and next to impossible to edit fully, unless using a text editor.

So if we do see more adoptions, it's quite likely they'll either end up incompatible with each other or some consensus on a work-able subset of SVG is reached.

Perhaps if W3C had done a reference implementation much like, say, H.264 has reference implementations, some of this could have been avoided?

I'd enjoy reading opposing views on this, interesting topic.

<comment><USER8> <http://www.w3.org/Amaya/> is a kind of reference browser from the W3C. The release history lists the first SVG support in Amaya 4.0 from 10 November, 2000.

<comment> jarek-foksa Amaya does not render correctly the most basic SVG files. Even IE6 would make a better reference implementation of web standards.

Batik seems to be the most well-tested and conformant implementation of SVG at the moment: <http://xmlgraphics.apache.org/batik/status.html>, though I would use WebKit as reference because of it's market share and potential of Google and Apple to change the SVG spec.

</comment></comment></comment></comment><comment><USER9> Why oh why did they not come out with a SVG 1.0 that was static and simple to implement. A resolution independent replacement for images.

Sigh, what might've happened...

</comment><comment><USER10> Totally expected this to be funded by DARPA</comment>


3D printing could be the next great technological disruption - <AUTHOR> http://www.economist.com/blogs/babbage/2012/09/3d-printing

<comment><USER2> I remember hearing about 3D printing in the late 90s. Isn't it taking a long time to see affordable 3D printers for consumers? Does anyone know what's holding it up?

Is it possible we'll never see 3D printers below $1000?

<comment><USER3> So why do they have to be less than $1000? Henry Ford disrupted things and never built a consumer version of the assembly line :-)

There is already use of 3D processes in specialist markets for production parts, those markets are training the people who build these things what is and what is not useful.

The 'home' 3D printing market is wicked fun but I don't know if it will ever be much bigger than the home 'machining' market is either. Time will tell.</comment></comment>


Vampire mice and zombie hard drives: USB dangers lurk in Linux  - <AUTHOR> http://www.networkworld.com/news/2013/091913-linuxcon-usb-273986.html

<comment><USER2> "One such issue affected a particular brand of portable USB hard drive. Sharp said that an alarming problem occurred when the drive attempted to come out of suspend mode."

Anyone know what brand of drive this is? I think it'd be nice to know to avoid it.

<comment><USER3> I'm really curious too, because I don't buy the explination of the problem myself.

> "The user hears this horrible scraping noise because the driver forgot to > park the disc head before it cut power to the disk," she said.

That shouldn't really be possible to cause that kind of damage, every modern drive I've seen (past 15-20 years?) has an automatic head return when powered off (usually magnetic or spring driven). This would be the same as just pulling the USB plug and having that result then.

</comment></comment><comment><USER4> "It's about four watts, if you just have one USB device that's not suspended," said Sharp.

How does that 4W number break down? Is the CPU forced to poll USB devices at 125Hz, preventing it from entering deeper sleep states?

</comment><comment><USER5> This is some silly shit.

Edit: I mean the article is silly.</comment>


Career Choice: Corporate vs. Startup - <AUTHOR> http://mittermayr.tumblr.com/post/16757008923/career-choices-corporate-vs-startup

<comment><AUTHOR> would love to hear your thoughts on this, right here</comment>


Show HN: Riptide – Find your next favorite podcast - <AUTHOR> https://riptide.fm/ <comment><AUTHOR> Hi everyone! I want to introduce you guys to this website I've been building. It's basically a "Reddit for podcast highlights" and my hope is that it will make discovering podcasts easier for those who are passionate about the space as well as lowering the barrier of entry for people that haven't gotten into podcasts. If you have any questions please let me know! Love to get any feedback :)

Cheers! Sean</comment>


Bill.com Files for $100M IPO - <AUTHOR> https://news.crunchbase.com/news/fintech-unicorn-bill-com-files-for-100m-ipo/ <comment><USER2> Somewhat off topic but, when I simply typed the site bill.com on Firefox's private browsing, scrolled down a bit, they show me a popup to chat and they have my first and last name there. The same thing happened when I went on my cell using Firefox Focus, which doesn't keep any cookies. 1\. Anyone else seeing this? 2\. I hate it 3\. Where do they get this info from?

<comment><USER3> Nothing for me.

This is a Drift chat widget so they have your information stored somewhere, probably from some interaction you had with it on a different site. They also appear to do IP lookup as well.

<comment><USER2> Thanks, it looks like it is IP lookup, I used another phone (not mine) and they also showed my name there.

<comment><USER4> ip lookup seems like a weird way to do name lookups...

<comment><USER3> They probably check the ISP to determine if the IP is static or not, and then map the name if it is.

</comment></comment></comment></comment></comment><comment><USER5> Important that they're aiming to _raise_ $100MM, not going public at a $100MM valuation as I first thought. Funny how IPOing to raise capital has become secondary to IPOing to provide liquidity in this late stage of the tech credit cycle.

<comment><USER6> Tech IPOs seem to be splitting into two very different tiers.

Some don't need the cash and may even do a direct listing with no capital raise, like Spotify and Slack.

Others have such huge losses that the IPO cash is acutely needed. I'd put Lyft and Uber in that bucket. WeWork of course is the poster child — it nearly collapsed after the IPO was pulled and cash from public markets wasn't forthcoming after all.

<comment><USER7> WeWork is not "tech IPO" though.

<comment><USER8> Whilst I acknowledge the technical correctness of your remark, in practice and for most intents and purposes, WeWork is being considered as a tech IPO

</comment></comment></comment></comment><comment><USER9> "We were incorporated in 2006 and have experienced net losses and negative cash flows from operations since inception."

13 years of unprofitability?

<comment> barry-cotter If you have positive return on cash invested people will be happy to keep giving you more money for decades even if you plough all your profits back into expansion. Amazon has had the option of returning profits for decades and has always aimed to just barely make a profit.

> Amazon was founded in 1994, first traded publicly in 1997, and didn't turn a > profit until 2001.

[https://www.investopedia.com/stock-analysis/031414/amazon- ne...](https://www.investopedia.com/stock-analysis/031414/amazon-never-makes- money-no-one-cares-amzn-aapl-wag-azo.aspx)

<comment><USER9> Amazon is clearly an outlier. Let's not equate every unprofitable company with them.

<comment> barry-cotter Not every company is Amazon but Bill.com is showing 57% year on year growth this year after 71% last year, with over $35m in quarterly revenue for the last quarter. With those kinds of numbers they can invest less in customer acquisition and turn on the money tap any time they want.

> Bill.com reported about $35.2 million in total revenue for the third quarter > of 2019, representing nearly 57 percent year-over-year growth compared to > $22.4 million in total revenue for the third quarter of 2018. For context, > Bill.com's total revenue grew 71 percent between the third quarter of 2017 > and the third quarter of 2018. The company's growth is slowing down, which > isn't unusual as companies mature.

<comment><USER10> > _With those kinds of numbers they can invest less in customer acquisition > and turn on the money tap any time they want._

Where does this notion come from that these companies can "make money whenever they want", but haven't done so in a decade or more? People point to Amazon as an analogy all the time: it took Amazon about 5 years to make a profit, and this was the early internet. Bill.com is not Amazon.com.

That's a _theory_ , a selling-point, and it comes from "Silicon Valley" itself. In reality, the growth tends to _come from_ the customer acquisition spend, and growth will likely cease the minute customer acquisition spending stops. Growth is already slowing down, and this company has never made a dime. So what value do _you_ put on it now?

Where does the idea assumption from that these companies are "putting profits back into the company"? That money has to show up in the financials statements as well, it's not magic.

<comment><USER11> If you have healthy free cash flow it's up to you what you do with it.

Jeff Bezos' letter to shareholders on this topic (PDF warning) — [https://ir.aboutamazon.com/static- files/2b0b9eb6-0e9d-40f9-8...](https://ir.aboutamazon.com/static- files/2b0b9eb6-0e9d-40f9-8708-f9f73d1ed485)

</comment></comment></comment></comment></comment></comment><comment><USER12> Not profitable, has never been profitable, its losses are actually growing over time in absolute terms, it's IPO'ing anyway...and yet, it looks (even to me) prudent and reasonable in the current climate.

</comment><comment><USER13> I used bill.com and ran quite a bit of money through there but I find the UX to be terrible. Second only to WorkDay.

I never asked but maybe the accounting team loves it. As an approver and receiver (separate companies) it never made sense to me. I used it only because I had to.

<comment><USER14> Checkout transferwise. Similar function, less jank

</comment></comment><comment><USER15> As a contractor, I've been paid via Bill.com it was very easy to collect and send money. (not like I had a choice in the platform)

<comment><USER16> Don't you have to pay to use that feature as a contractor? Isn't that an unnecessary tax?

<comment><USER15> No, I assume it was paid by the company paying me.

</comment></comment></comment><comment><USER17> I have never had a good experience with their platform, or their customer support.

I've had an account bug with them for over a year, and every time I reach out to their customer support they just tell me I'm wrong and everything is okay with my account... Meanwhile, the dashboard is essentially "bricked" for me and I have to send invoices to my customer via email (how I prefer, but not how my customer that pays all their bills through bill.com prefers).

</comment><comment><USER18> Are they a direct competitor of Stripe?

<comment><USER19> Accepting ACH payments on larger client invoices (30-100k+) for a few dollars is why we use them at one company.

<comment><USER20> Is the experience sticky? Stripe supports ACH transfers, so I would assume it would be straightforward to build on top of Stripe to replicate bill.com's functionality.

</comment></comment></comment><comment><USER21> Would this make them a "centi-corn"?

<comment><USER22> Not sure if the joke was if they were valued at $100M or not. But they last raised at Unicorn valuation. If they're selling 10% of the company or less for $100M, then they'll still be a Unicorn.

<comment><USER23> I think that was the joke. I thought that's what the headline meant at first too. The headline could have been clearer.</comment></comment></comment>


The Making of Doom: Id's shooter masterpiece - <AUTHOR> http://www.pcgamesn.com/article/making-doom-ids-shooter-masterpiece <comment><USER2> If you have not yet read "Masters of Doom", I strongly advise any aspiring hackerpreneur to read it. It's an enthralling and easy read and details the early day of id, including the releases of their breakout hits "Commander Keen", "Wolfenstein 3D", "Doom", and "Quake", as well as the fall of Romero, following his departure from id, particularly with the "Daikatana" flop.

[http://www.amazon.com/Masters-Doom-Created-Transformed- Cultu...](http://www.amazon.com/Masters-Doom-Created-Transformed- Culture/dp/0812972155)

I read it when it was new 8 years ago, and I think I'm probably due for another reading, myself.

<comment><USER3> One of my favorite books. Almost makes me wish I was born at a different time and place.

Even the Super Mario Warner Bros 4 rewrite Carmack made is two days older than me.

<comment><USER4> >Almost makes me wish I was born at a different time and place.

I've often found myself feeling the same way.

Thing is, we're in no danger of running out of things to invent or advance. There's effectively just as much uncharted territory for us as there was for anyone else. We even have the benefit of standing on their shoulders to achieve perspectives they couldn't realize.

<comment><USER3> This is true, hence my use of "almost".

On the other hand, there is a lot magic to eating pizzas and sipping diet cokes in the house by the lake only to play and make games.

I just no longer see myself being able to be blessed by that privilege.

<comment><USER5> what's stopping you? there's people doing that even today in 2012.

</comment></comment></comment></comment></comment><comment><USER6> Reading about Doom in a historical sense, I always find that there is a bigger absence of emphasis on the ability to modify the game than there should be. Doom not only revolutionized gaming and the FPS genre, it tore open the doors for game modifications. Projects like DeHackEd[1] allowed us meddling kids to start to see the possibilities of modifying our games at very fundamental levels. Sure, you could open a hex editor and edit Ultima VII to make your own maps, but Doom, DeHackEd and WAD editors meant you could, relatively easily, modify and share your creations.

Aliens TC[2]. The Energizer Bunny[3] mod. These were the beginnings of what would later become some of the most popular games that have ever come out for the PC. Being able modify a game and engine allowed for things like Counter- Strike[4] and Team Fortress[5]. Anyone else remember QTF or Beta 5.3? These humble beginnings of shared modifications grew into entire empires and created celebrities in the game development world. The gamers needed new heroes that weren't all caught up in ridiculously silly enterprises like Daikatana[6]. They needed cliffe[7] and goose[8]; independent developers working on something incredible for everyone to enjoy. From small teams to huge mega corporations and back again, game modification has had a lasting and incredible impact on the PC game market and will continue to for a long time.

We have Doom to thank for this. Now, where are my serial cables? I wanna do some multiplayer fragging.

[1] <http://en.wikipedia.org/wiki/DeHackEd>

[2] <http://doom.wikia.com/wiki/Aliens_TC>

[3] <http://www.doomworld.com/idgames/index.php?id=68>

[4] <http://en.wikipedia.org/wiki/Counter-Strike>

[5] <http://en.wikipedia.org/wiki/Team_Fortress>

[6] <http://en.wikipedia.org/wiki/Daikatana>

[7] <http://en.wikipedia.org/wiki/Jess_Cliffe>

[8] <http://en.wikipedia.org/wiki/Minh_Le>

<comment><USER7> Not just the mods, consider the tools as well. As far as I can recall id Software rarely released their own tools for content creation in the early days. Often because their tools were made to run on expensive industrial strength computers, especially in the Quake days. They only just described in various ways how to create content for their engines and/or released source code to their tools.

If the tools people didn't step up to create these things then the mod scene may not have turned out the way it did. This tool creation "scene" led to some interesting creations that the industry benefits from today. For example, we had Worldcraft until Valve hired the creator and made it into Hammer; which is still in use today.

This type of thing doesn't really exist as much today simply because most of the common engines are supplied with content creation tools out of the box. Part of me longs for the days of exploring new crazy ideas that was done back then. I knew a guy that designed his first few levels in Quake with notepad (three dimensional BSP node coordinates by hand!), graph paper, and the compile tools until editors starting showing up. To pat myself on the back I built the first Quake2 "unit" of levels (AFAIK) to be released and I did that by opening the compiled id BSP files in notepad and followed the trail of entities through the plain text. Those were fun days.

</comment></comment><comment><USER8> Doom defined my childhood. I was lucky enough to have an older brother who was really into computers and knew how to get Doom multiplayer working over serial cables. I can remember being blown away by the first multiplayer FPS experience I'd ever had. Some of my best memories were spent fragging our friends while Rush or Dream Theater played in the background. The mods were amazing too. We would mess with the firing rate of the different weapons to create an entirely new experience. We found user created levels to play, too. Our favorite was a map entitled butt.wad (wow, I only just now got that joke) which had the Marriage of Figaro playing in the background. I even got into modding myself, creating maps and re-skinning characters in the game. Man those were good times.

<comment><USER9> I could have written that comment (except for the brother part -- I was the one who introduced my friends to DOOM). So many good memories doing 4-player LANs... Wish I had a time-machine sometimes..

</comment></comment><comment><USER10> _John Carmack said no. "Story in a game is like story in a porn movie, he said. "It's expected to be there, but it's not important."_

I love this quote. I think many of today's AAA game designers need to take heed.

<comment><USER11> Maybe for some games, but for others it's nice to see some elements of great story-telling.

Of course, you still want to have good game mechanics, interactivity, graphics and fun, but the medium has evolved to the point where you can tell a good story.

<comment><USER12> I think it's very much a quote of its time - I agree with you that the problem is primarily one of medium, and at that time the medium wasn't able to adequately tell complex, compelling stories.

The market has definitely evolved now - there's still a demand for great action games where story takes a back-seat to the sheer enjoyment of playing, but there's also demand for games with compelling stories (just look at the backlash Mass Effect 3 had, rightly or wrongly). It's like films, or TV - sometimes you just want to watch big things blow up, other times you want things that make you think.

</comment></comment></comment><comment><USER13> Another notable thing about DOOM was that it was unabashedly written in 99.9% C, with only a few ([http://code.metager.de/source/xref/idsoftware/doom/README.as...](http://code.metager.de/source/xref/idsoftware/doom/README.asm)) exceptions for rendering inner loops. The myth that a performant game required copious assembly code was on the ropes at this point, but DOOM completely killed it (as did having faster/better compilers and CPUs).

<comment><USER14> Even Quake optionally used some assembly code. According to <https://github.com/id-Software/Quake/blob/master/readme.txt> the plain C version was running at half the speed of the one compiled with the assembly code, when not relying on hardware graphics acceleration.

</comment></comment><comment><USER15> What a coincidence, I've been playing Doom 2 for the first time over the last couple of days. I've also recently replayed the first, but I had actually played that back when I was in primary school (behind my parents back of course).

I'm surprised just how much fun it still is and if you use something like ZDoom [1] (which I have been) you can literally just run the binary with no setup and it runs flawlessly on a modern system.

One thing that really stuck out to me as I've been playing it is that there really isn't anything from modern shooters I miss. I'm not trying to diminish the work that has been put into AI, Physics, Graphical fidelity etc, but what does it say about the genre when you can remove all the innovations over the last 20 years and it's not any less "fun"?

[1] <http://zdoom.org/>

<comment><USER16> Jumping, mouselook, crosshairs? That does not sound like Doom to me. Give <http://www.chocolate-doom.org/> a try, that engine is faithful.

<comment><USER15> I'm not playing with any of those things so they must be off by default. I'm just using it as a way to be able to easily run it on a modern system without having to mess around.

</comment></comment></comment><comment><USER17> "Players can play the entire game from the map mode. Zoom in close enough and you can even see individual bullets flying around the levels."

I don't remember that from the original Doom? I didn't think you could see any other 'things' on the map, let alone that the bullet weapons are hitscan so don't have any projectiles flying about.

Am I misunderstanding what they mean here? Or is my memory just failing me?

<comment><USER18> I can't recall if it required a cheat or not (secret stuff didn't show up on the map by default), but you could absolutely see every entity in the level from the map screen.

This included enemies, projectiles, powerups, bullet sparks and assorted decorations. Many of them were shown as little arrows indicating which direction they were facing.

</comment></comment><comment><USER19> If you've not read Masters of Doom, do so now. It is an amazing read.

</comment><comment><USER20> Oh man that was an awesome game. I used to stay until 11pm at night playing colleagues over the Lotus network. And then once we found out how to download wad files from some US university over FTP...

Mind you, walking out through a darkened office with lights turning on and off used to give you a few flashbacks...

</comment><comment><USER21> Doom was the reason for building my first PC. Anyway, many years later, I read and studied doom source code, mostly to see how the game engine worked. I had it printed out on paper and read it line by line and found it to be very readable, and even entertaining.

</comment><comment><USER22> edit: Hall, humiliated, quit midway through 1983, should read 1993

</comment><comment><USER23> A little violent game

<comment><USER24> I know this is an utter troll, but I think it is worth broadcasting to any HN member that DOOM is a notable feat of software engineering: not only did Carmack invent and perfect a wide variety of technologies, they also included what was the first seriously adopted modding kit that lead to a lot of people being introduced to game modification and programming.

<comment><USER25> Doom did not include a modding kit. All utilities were made by fans. Modding was easy in part because the engine had been designed to load all game content from separate, easily modified .wad files. (The rampant popularity of the game itself also helped pave the way for a modding community, of course.)

<comment><USER26> That's not actually true. Carmack uploaded the source for the level editor and utilities for modders to use. The modding community just made much better and easier to use tools. .wad files were also created specifically to encourage modding and make it non-destructive.

Excerpt from Masters of Doom:

> Though Carmack and Romero were intrigued and inspired by these actions, they > were concerned over the destructive quality of the mods. Players had to > erase the original Wolfenstein code and replace it with their own images; > once a Nazi was changed into Barney, there was no way to bring the Nazi back > quickly. For Doom, Carmack organized the data so players could replace sound > and graphics in a nondestructive manner. He created a subsystem that > separated the media data, called WADs (an acronym suggested by Tom Hall, it > stood for Where's All the Data?), from the main program. Every time someone > booted up the game, the program would look for the WAD file of sounds and > images to load in. This way, someone could simply point the main program to > a different WAD without damaging the original contents. Carmack would also > upload the source code for the Doom level-editing and utilities program so > that the hackers could have the proper tools with which to create new stuff > for the game.</comment></comment></comment></comment>


Show HN: Pomodoro timer - <AUTHOR>

For the pomodo lovers out there.
This is a basic side project of mine to use new knowledge recently acquired (been learning javascript with the codeyear initiative and some jquery here and there).
http://mintypt.github.com/pomodoro/ <comment><USER2> The pause and continue buttons are broken for me. If I click on a time other than 25, the pause button breaks. If I use 25, I can pause, but not continue.

<comment><AUTHOR> Should be ok now :)

</comment></comment><comment><USER3> Nice job in adding some personality to bootstrap!

<comment><AUTHOR> Yeah, I didn't wanted it to look like all the other site sing the bootstrap out there. :)

</comment></comment><comment><USER4> Cool idea, but for some reason it counts way too fast in my browser. It cranked out the 5-minute pomodoro in less than a minute. FYI I'm using Chrome on Ubuntu

<comment><AUTHOR> Check it now. Should be working. :) Thanks for reporting this.</comment></comment>


The Most Useful Objective-C Code I've Ever Written - <AUTHOR> http://vgable.com/blog/2010/08/19/the-most-useful-objective-c-code-ive-ever-written/comment-page-1/

<comment><USER2> Here's the Borkware NSLog replacement:

<http://www.borkware.com/rants/agentm/mlog/>

There are others.

<comment><USER3> The Borkware NSLog replacement seems like a rather a large amount of overkill and unnecessary clutter. __FILE__ and __LINE__ should always be implicit parameters instead of having to be passed into a method, every time. Not a MLog() wrapper that calls a singleton to make them implicit.

I personally like to define a Log() as:

      #ifdef DEBUG
    	#define MYLog(fmt, ...) NSLog(@"%s: " fmt, __PRETTY_FUNCTION__, ##__VA_ARGS__)
      #else
      	#define MYLog(...)
      #endif

This way, I can log on debug builds only (add -DDEBUG as an "Other C Flag" to Xcode), and it gives me the method name that it was called on. Just enough context to be useful to track something down, not enough to cause a sea of output noise.

You can use any of the C preprocessor macro's[1] this way.

1\. [http://gcc.gnu.org/onlinedocs/gcc-3.1.1/cpp/Standard- Predefi...](http://gcc.gnu.org/onlinedocs/gcc-3.1.1/cpp/Standard-Predefined- Macros.html)

</comment></comment><comment><USER4> It can be improved, here's my version from a c program but can be used in objc in the say way.

<http://pastebin.com/nbgdaGXJ>

<comment><USER5> IIUC, your implementation does not solve the same problem.

The OP's implementation automatically determines the correct format string from the type of the variable. So you can simply do:

LOG_EXPR(some_int); LOG_EXPR(some_float); LOG_EXPR(some_complex_cocoa_type);

</comment></comment><comment><USER6> Wow, is the typesetting royally screwed for anyone else?

See <http://i.imgur.com/Doy2r.png>. Seems to happen whenever he switches to something like a code fragment or italics inline.

<comment><AUTHOR> Render fine for me under OS X 10.6.4 both:

\- Chrome: <http://emberapp.com/pietrofmaggi/images/google-chrome>

\- Safari: <http://emberapp.com/pietrofmaggi/images/safari>

BTW: the article is not mine, I just posted it on HN.

</comment></comment><comment><USER7> I have always wanted this for every programming language I had whenever I typed "printf("somelongvariable=%s", some(CTRL-P));"</comment>


SSH Key Audit on Github (required) - <AUTHOR> https://github.com/settings/ssh/audit <comment><USER3> What makes me the most happy about this is that they ask for the password in order to add a key now.

I was always very afraid of XSS attacks (I know - there shouldn't be any - <USER2> there could and were, though not for this) that would add another key, so I always hoped they would add that additional bit of protection.

As such: Another huge thanks to @homakov for forcing the issue.

<comment><USER4> This change is orthogonal to @homakov's attack. Silently changing the user id on a key wouldn't generate an email.

<comment><USER5> The change is good and was quite clearly precipitated by Homakov. Thus it seems entirely reasonable to thank him. So I don't see what your point is beyond irrelevant pedantry.

<comment><USER6> I don't think it's pedantry. I think it's good to point out that while this change is good, and is in the same realm, if you give the impression that it would prevent an attack like the one this weekend, it's security theater.

<comment><USER3> It doesn't and I really hoped that I was clear enough in my initial comment. I know that this has _nothing_ to do with the attack on Sunday.

But ever since that XSS vulnerability was shown maybe a year ago, I was scared that there could be another one of them as they are very, very easy to miss, especially when you have to rely on filtering instead of escaping.

Github has to because you can freely use HTML in Markdown, which is the main markup language on github.

So there we are: Relying on filtering out bad stuff from user content, instead of blindly escaping it, at least one XSS vulnerability already happened and the public key interface still allows adding keys without confirming the password.

It would really suck to be hit by a XSS attack that silently adds a key to my account, not only giving the attacker the possibility to impersonate me in commits, but, even worse, giving access to my private repositories.

Regardless of the fix for the problem on Sunday, I have always hoped Github would add the check for the password. Not to mitigate the mass-assignment problem, but to prevent a possible XSS attack from being used to deal much worse damage.

I see this package of changes that we see now happening at Github as a direct result of the Sunday hack, so while we got the mass-assignment fix ( _of course_ that had to be fixed), we _also_ finally got the password recheck which we likely would not have gotten without the hack.

Hence my "thank you" to @homakov. Not just for uncovering the mass-assignment thing (which is a simple code fix), but also for forcing a change of policy (with negative usability repercussions and thus probably not universally accepted between github internals) elsewhere.

</comment></comment></comment></comment></comment><comment><USER7> Here is the command you use to obtain your fingerprint for this audit:

`ssh-keygen -lf ~/.ssh/id_rsa.pub`

<comment><USER8> Thanks for this. I found it kind of weird that the email they sent didn't include any instructions on what to do. The linked webpage didn't have any guidance either. I guess they assume we all know what to do.

<comment><USER9> This. In fact, it creates an even more dangerous situation, as users could go to the site, see their keys, and say "I dunno. Looks fine?" and approve all of the keys, without actually confirming that the keys are legitimate.

Not giving instructions _on the page_ on how to verify the info was weak. Github people, if you're reading this, please update that page.

<comment><USER10> I very much agree they should have added instructions to the page. However when I went through the process there was a prominent note saying that when in doubt, you should reject keys and upload new ones. So the "I dunno. Looks fine?" case seems like it would be a problem only for the careless.

<comment><USER11> Sort of like how the Rails default settings only caused problems for the careless....

I bet a lot of people would have verified their keys with instructions but didn't bother without.

<comment><USER12> Disagree for anyone with more than one key. The problem with verifying all your keys at once is that I'm not going to find all my devices (I don't practice falconry). It would have been better if you could delay answering for some keys. I'm not sure you could have, but I didn't feel that way when performing my audit so I accepted them all, they all had recognizable hostnames.

<comment><USER11> It looked like you could put off dealing with keys by just not doing anything to them. Anything you didn't approve or deny would stick around. However, I didn't actually test this, and I only had one key which is now approved so it's too late.

<comment><USER13> That is correct I did exactly that. I got the message at home, and I had a key for a work computer on there, so I confirmed the home keys and left the work key disabled.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The accompanying email:

      A security vulnerability was recently discovered that made it possible
      for an attacker to add new SSH keys to arbitrary GitHub user accounts.
      This would have provided an attacker with clone/pull access to
      repositories with read permissions, and clone/pull/push access to
      repositories with write permissions. As of 5:53 PM UTC on Sunday,
      March 4th the vulnerability no longer exists.

      While no known malicious activity has been reported, we are taking
      additional precautions by forcing an audit of all existing SSH keys.

      # Required Action

      Since you have one or more SSH keys associated with your GitHub
      account you must visit https://github.com/settings/ssh/audit to
      approve each valid SSH key.

      Until you have approved your SSH keys, you will be unable to
      clone/pull/push your repositories over SSH.

      # Status

      We take security seriously and recognize this never should have
      happened. In addition to a full code audit, we have taken the
      following measures to enhance the security of your account:

      - We are forcing an audit of all existing SSH keys
      - Adding a new SSH key will now prompt for your password
      - We will now email you any time a new SSH key is added to your
        account
      - You now have access to a log of account changes in your Account
        Settings page
      Sincerely, The GitHub Team

      --- https://github.com email@example.com

</comment><comment><USER15> Why are ONLY keys at risk, which this implies?

Presumably someone could have added a key, done evil, then removed the key. Evil includes all sorts of interesting things, like checking in code under the name of an existing contributor. This could potentially be really subtle and would be difficult to find in an audit later.

(Remember the stink over OpenBSD potentially having backdoors in the IPsec stack, revealed in late 2010? <http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd>)

<comment><USER16> I thought git itself provides authentication and integrity? In fact, if someone modifies the history of a branch that will raise all sorts of red flags the next time a legitimate user pushes.

<comment><USER15> Not modifying stuff on disk outside git, but using substituted keys to masquerade as a legitimate user and contribute evil code. It leaves an audit trail, but means you need to audit all contributes even those ostensibly from project owners.

</comment></comment></comment><comment><USER17> They also did a notification when you tried to push:

ERROR: Hi andrewjshults, it's GitHub. We're doing an SSH key audit. Please visit [https://github.com/settings/ssh/audit/<removed>](https://github.com/settings/ssh/audit/<removed>); to approve this key so we know it's safe. Fingerprint: <removed> fatal: The remote end hung up unexpectedly

A little weird to see when you're doing a push but good that they put it in there. Their email got flagged as bulk in gmail so until I saw this I didn't know they were doing the audit.

<comment><USER18> > "good that they put it there"

I think this was handled very badly. This broke alot of automated jobs for many people. The email actually arrived after some of our automated jobs had stopped running. There should have been an advanced warning that such an audit would take place. I'm glad we had monitoring on our automations, but many people won't have those and might still be unaware that they are not running until they authorize their keys.

</comment></comment><comment><USER19> Sadly the link in the email isn't direct (it's a tracking link through "news.github.com"), so Thunderbird flags it as a possible phishing attempt =(

Edit: github send out an email with a link to the ssh audit page; that's the email to which I refer

</comment><comment><USER20> As an interesting side effect, they will have pretty exact stats on how many active users they have; might help them sunset old accounts or move them to the slowest servers.

(Because of the offline nature of most git actions and different habits on pushing/pulling, it's probably hard to otherwise estimate how much a user cares about their github.)

<comment><USER21> Why is this more effective than say "number of push / pulls in the last month"?

<comment><USER20> Some people try to pool local commits into larger, less frequent pushes and pulls so the number of push/pulls is perhaps less relevant than their cumulative size. But pushes/pulls will never correspond well with user involvement because people use github for all kinds of scenarios. For instance, I might be developing branches that I don't want to push or pull to github yet--maybe I don't even intend to ever make them public. However, I may still want people to clone from my github repo and report issues to me.

The amount of time between someone getting an email from github and re- activating their account is probably the best metric github will ever have on users' attachment to their accounts.

</comment></comment></comment><comment><USER22> Correct me if I'm wrong but the nature of the vulnerability was that someone who's _not_ you had to submit a page with certain POST variables they could have determined after the fact to be malicious while logged in.

So the fact that they're sending out this E-Mail tells us that they either don't keep logs on requests + POST contents, or that they haven't had the time or inclination to analyze this data if they have it.

<comment><USER23> Or they realize that psychology is just as important to security (and customer confidence) as logs, analysis, and good code.

Every person that got this email now feels more secure about Github. They audited their own private keys. They were reminded that they can remove keys at will. And they know Github has improved its code and given users more power (email alerts, etc) to be in control of content.

<comment><USER22> I for one am feeling way less confident in them with every announcement they make. They clearly have no idea if and how they were exploited, and their communication with their users only asks their users to check for one attack vector, while in actuality the attack was _not_ limited to just adding ssh keys.

</comment></comment></comment><comment><USER24> I guess this answers my questions about how long this vulnerability existed (a long time) and whether or not they could verify no other accounts were compromised (no).

</comment><comment><USER25> Um, is anybody else having the experience that their keys really do seem to be different?

<comment><USER26> You should probably tell GitHub

<comment><USER25> I thought I deleted this comment. Sorry. Turns out I had an old key still in my .ssh folder. Two current and valid keys and no others. My bad.

</comment></comment></comment><comment><USER27> It would be interesting to know the details of the vulnerability. Given that they've patched it, it would be good to see what the error was in case others are affected.

Was this Rails-related and what was it?

<comment><USER28> There are a number of articles that surfaced on Sunday/Monday, but in short, yes - it was a Rails mass-assignment vulnerability.

<comment><USER29> I'd like to point out that this is not a rails vulnerability, but a mistake Github engineers made, which happens to the best of us. Mass assignment is a feature and I guarantee the problem has been know for years and Github engineers were probably well aware of it.

<comment><USER30> It most certainly is a vulnerability in rails, by encouraging bad practice by design. Mass assignment should work by defaulting attributes to protected, if it should exist at all.

</comment></comment></comment></comment><comment><USER31> [http://unix.stackexchange.com/questions/2116/given-keys- in-s...](http://unix.stackexchange.com/questions/2116/given-keys-in-ssh- authorized-keys-format-can-you-determine-key-strength-easi/2146#2146)

This script is very useful when doing this audit, because you can turn your .ssh/authorized_keys file into a list of key names and fingerprints to check against what github is showing you.

</comment><comment><USER32> I've just registered yesterday on Github (it's suggested for Coursera's Saas Class i'm attending) but they've sent it to me too, even though the vulnerability has already been resolved _before_ my account was created. Maybe they've not checked account age..

<comment><USER33> I suspect that since they only closed the hole late Sunday or early Monday, that they decided the number of new accounts was so small, it wasn't worth introducing the complexity (and potential bug/insecurity sources) to handle such a small percentage of the user-base. A reasonable tradeoff since getting this audit done in a timely manner is more important than waiting to handle edge cases such as yours.

</comment></comment><comment><USER34> Why are you guys praising GitHub? They basically screwed up thrice: first by not catching such an obvious flaw (granted it should have been changed in Rails, but still), second by breaking half the scripts that rely on their service and finally by sending such an obnoxious email (really required action? Who the hell to do you think you are?).

Anyway it is pretty moot at this point since I have long ago forgotten my password and changing the orgion to somebody else is pretty easy.

That said, can anybody recommend alternatives? I know Bitbucket and they seem pretty great, especially as they allow private repositories, but it seems the consensus here doesn't like them for some reason?

<comment><USER35> I love Bitbucket and have been using them exclusively for a long time. I have many private repos histed there for free. I have several private repos there shared between a few users, also free. I'm unnerved by how they havent asked me for money, but grateful. Free jira, wiki, and hipchat, too.

I'm a Mercurial guy, but they do git too.

</comment></comment><comment><USER36> Is it a good idea to check created_at != updated_at ?

People update public keys very rarely. I would even say NEVER.

Just make an sql against your table to see what are the most possibly are malicious keys.

(i see no reason to update timestamps doing 'the trick'. I believe attackers didn't)

<comment><USER37> The vulnerability probably also allowed the attacker to edit the created_at and updated_at columns in the ssh key table.

</comment></comment><comment><USER38> Several comments below praise the Github team response to this vulnerability. I agree. But it should also be mentioned that the first email I sent to my company this morning read, "should [our product] source code be in the cloud?"

<comment><USER15> At the very least, I think it is irresponsible for your product's source code to ONLY be in the cloud. Luckily git provides an easy way to keep a mirror (it's kind of automatic), but some kind of regular off-github backup, signing, etc. would make a lot of sense.

<comment><USER38> This is a vulnerability where an attacker would be able to add his SSH key to a private repository and pull proprietary source code he was not authorized to see. This is why we pay for Github, not use a free account. We don't want people to be able to walk off with the intellectual property of our company.

That being said, we don't have the resources to deploy a more secure alternative without hamstringing our development capabilities (e.g. no internet connectivity).

<comment><USER15> Oh, I agree. I'm just saying the baseline for everyone should be backups and integrity checking. A lot of companies don't have great value in their code remaining confidential, a lot do, so that has to be factored in. Other infrastructure (including runtime environments/hosting) need to be factored in, too, and there's confidentiality plus a lot of other concerns like availability.

Why isn't Github Enterprise an option for you? Too expensive? (plus of course you have to run it; if you don't have a good VPN or premises network, sysadmin resources to run it, etc., it's entirely possible a self-hosted thing could be less secure than a SaaS solution)

(The irony of my running a cloud tech startup and not trusting "the cloud" for our source control, email, file storage, compute, ... is not lost on me. It definitely adds costs, but I think this is an appropriate level of paranoia. The providers of business services need to provide convincing arguments why their services are secure enough to use, at least for b2b.)

<comment><USER38> You hit the nail on the head. Github Enterprise is too "expensive" in attention required. While we are security-minded about our proprietary code, we also recognize that we have a limited budget for "distraction overhead." We chose infrastructure largely based on how little we have to think about it. In this case, the distraction cost would be significantly higher than the risk- weighted cost of IP theft. I still would prefer to minimize that risk, but without the additional staff and systems you mention, the only reasonable alternative we have is a local server with no internet connection. Alas, connectivity is a fundamental requirement.

</comment></comment></comment></comment></comment><comment><USER39> It was easier for me to just delete all of the keys. I had some I didn't need anymore. I also didn't pick great names for the keys I had. It's easy to add a key so instead of checking the fingerprints I can just create a new key.

</comment><comment><USER40> I've just seen it and I headed to Hacker News to verify if it was legit :)

<comment><USER41> Same here, wasn't sure seeing no reference to github.com in mails' header, even if the link pointed directly on their domain.

i guess that's the precise moment when I should feel _too_ _much_ paranoid.

</comment></comment><comment><USER42> Damn I envy the GitHub guys. They can send a mail to their users about SSH Keys and nearly all users simply understand it and get it over with.

In any other business, the result of a similar mail would be an overloaded helpdesk, a significant reputation hit and a massive bucketload of competitor FUD.

</comment><comment><USER43> They also added a audit log so you will be able to track and address any future issues.. <https://github.com/settings/security>

</comment><comment><USER36> you got balls guys. It is hard to force everyone to do something but you did it. Kudos

also, if we go back few years ago this way would be a bit secure to handle keys @key.body = params.. @key.title = params.. I am sure update_attributes is good choice when you got 5+ fields and update database scheme pretty frequently. Just my 2 cents

<comment><USER44> We sent someone back in time to make this change. Somewhere there's an alternate universe with a secure GitHub by default. Thanks!

</comment></comment><comment><USER45> while this was a good response to their security issue a little heads up would have been good. they broke all of our auto builds and by the time we figured it out the guy who's key was used for the builds was gone on his vacation. luckily, we got ahold of him prior to him turning his phone off.

</comment><comment><USER46> Did this change just disable re-use of deploy keys across multiple repos?</comment>


What does this C# code look like in F#?  - <AUTHOR> http://lorgonblog.spaces.live.com/Blog/cns!701679AD17B6D310!725.entry <comment><USER2> Serious query: is it acceptable to pronounce F# as "G-flat" in a pinch?</comment>