ZFS on Linux 0.6.1 released: Ready for wide scale deployment - iso8859-1 https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups#!topic/zfs-announce/ZXADhyOwFfA

<comment><AUTHOR> So the two things I don't see are a comparison with BTRFS in terms of speed, and stability. I know ZFS is cool, but while we were waiting for it BTRFS got pretty darn good. I know ZFS has some additional features that BRTFS doesn't have, but If I have to use a unstable or slow filesystem to get those features when I could use by perfectly stable and fast filesystem while I wait for a few nice features I am going to say ZFS has missed its oppertuinity

<comment><USER2> Btrfs is actually a sordid state of affairs. It's been "two years out" for five years, which seems very disingenuous looking back. Groundbreaking FS development follows a pretty regular formula. 10 years seems to be the magic number. Major functionality (i.e RAID 5) is still just landing and has glaring issues. It's just now a couple years out.

Meanwhile, ZFS has over 10 years of history, stably implements most of Btrfs _planned_ features, and has battle tested deployments. Granted, the SPL for Linux adds variables, but there are some big users of this particular project.

So I approach Btrfs with the exact opposite mindset. It's guilty until innocent despite some FUD from the Linux camp early on that has settled down a bit since Oracle now has it's hands on both.

<comment><USER3> We have deployed ZFS for the last few years on some large backup servers (Solaris and FreeBSD) and our experience has been pretty rotten - the command line is slow at managing a few hundred volumes, it becomes unusable during a rebuild, and it has / had a rotten bug where if you fill a volume up to 100%, you need to allocate more space before you can delete it.

It's been a multi-year mistake for us and we're busy changing these servers back to nice simple XFS volumes.

<comment><USER4> And if you use more than 80% space performance degrades like a dog. We still use XFS for really large volumes though and it has always been fast and never missed a beat.

</comment></comment></comment></comment><comment><USER5> I think Oracle's decision to not keep Solaris open source, at least the ZFS portions, is enormously shortsighted.

The fact that there is a ZFS implementation (with so many of the original ZFS engineers behind it) still being developed in the open and used by multiple operating systems, but especially the Linux juggernaut, shows that Oracle really doesn't have any benefit to keeping it closed any longer.

It has forked.

We now have the Oracle ZFS with features and functionality that is not in the open source variant, and the open source ZFS that is apparently adding features and commands that are not in the closed source ZFS.

A huge selling point for the open source implementation is the fact that if you decide to change vendors or OSes, you can easily do so without having a huge data migration (zpool export on the old, zpool import on the new).

Except, for Solaris 11+. You can't go back and forth between them, so once you're on Solaris 11, you're stuck.

Yes, _this is most definitely FUD_ , but I can easily see this being used in the not-so-distant future once Linux vendors start supporting/advertising it for themselves.

I think that if Oracle were to open (and keep open) the newer releases (even if a few releases behind, like they were originally claiming they would), it would eliminate that argument completely.

Personally, I'd be absolutely thrilled with a cross-platform on-disk ZFS (I triple-boot Linux/OSX/Solaris on my notebook).

Professionally, I'd love to see a cross-platform on-disk ZFS simply to be able to throw the appropriate OS behind the data.

<comment><USER6> The big thing missing from the OSS implementations that Oracle 11 has got is FDE.

It's possible with dmcrypt and LUKS, but you void most of the reasons for using ZFS. encryptFS is also a possibility, but it's both _much_ less secure (an attacker can run ls) and also drops a few ZFS features like dedup.

Meanwhile, Solaris 11 has FDE that actually works, and there seems to be no serious FOSS effort either to reverse engineer their work, or to design something better.

In 2013, no software developer should be storing things without FDE unless they have unusual physical security measures. That makes FOSS ZFS a non- starter for most of the people who would use it.

<comment><USER5> Filesystem encryption is very handy for a notebook computer (I use it, myself), but in a datacenter it's value is a bit more questionable.

Where do you store your encryption keys? If they're on a removable USB device (for example), you'd have to contact the datacenter personnel to plug them in in the event you had to reboot (which happens from time to time if you perform OS SRU uprades). If the USB device is left in the server and someone gains privileged access to the machine, they've got the key as well as the data. If the USB device is _not_ in the server and someone gains privileged access to the machine, they _still_ have access to the data.

The only time disk encryption is valuable is when the machine is off or the disks are being transported.

<comment><USER6> > The only time disk encryption is valuable is when the machine is off or the > disks are being transported.

I'm thinking about the case where you have a computer in the home or office environment, e.g. the burglary attack vector. It's not just notebooks that get stolen.

I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents. In this case you are typing the keys in on boot, and you either ignore the RAM extraction attacks (which are difficult to execute in practice for non-academic attackers) or you can mitigate them by storing in L1 cache and so on.

Datacenters have unusually high physical security, and in addition I don't generally store highly sensitive data there (my work doesn't involve PCI compliance etc.) Whereas I do have PCI-level data about myself on my own computers.

<comment><USER5> "It's not just notebooks that get stolen."

Very good point. I guess I've been working in environments with datacenters too long. :)

"I'm also considering the corporate or government espionage vector, where you have a reasonably skilled on-site attacker trying to read or modify the disk contents."

Again though, that only protects you if the disks are out or the machine is down. If you have someone with that level of skill within your organization, they'll likely gain access to the running computer where the data has already been made accessible in decrypted form.

</comment></comment></comment></comment></comment><comment><USER7> If it's ready for wide scale deployment, I wonder why the team decided against signaling that by calling it 1.0 instead of 0.6.1. A version number < 1 makes me think the developers still think it's pre-release quality. That may not be the case here, but it makes me wonder.

<comment><USER8> No, I can assure you we definitely do not think it's "pre-release" quality. I work closely with Brian Behlendorf, and I'm sure he would not have made the stable release if he thought it wasn't ready for prime time.

It's a little disheartening to see people pay so much attention to a fictitious number, which really has no regard to the actual state of the code/project. Whether v1.0 or v0.1 was used, the quality of the release would not differ any.

<comment><USER9> We can't easily know the state of the code, but we can easily read the number that _you_ have assigned it. That number should reflect your own assessment of the code's stability.

It's also a matter of how much cognitive load you want to impose on your users. We use dozens of different open-source packeages, each with its own version number. Can you really expect us to keep track of all of them? "Which Linux ZFS release was the first stable one?" "Uh, I think it was 0.6 something, or maybe 0.5.1?"

Don't do that to your users. Call it 1.0.0.

<comment> j-kidd > We can't easily know the state of the code, but we can easily read the > number that you have assigned it.

Exactly. To those who have been using 0.6.0_rc*, version 0.6.1 conveys the meaning "go ahead and upgrade, here's the stable release with no backward compatibility issue".

You will get your version 1.0 after several pre-1.0 RC releases. That's the proper release management.

</comment></comment></comment></comment><comment><USER10> Never mind all the promised wondrous features of ZFS, what are the recovery / fsck tools like? If the data recovery tools aren't mature, reliable and useful, then I'd advise anyone to stay away from a filesystem, no matter how world-ready the underlying FS code is.

I'm probably biased; but I got screwed using ReiserFS. It was fast and great, but one day something went wrong and then I found that the reiserfsck program was practically useless. Very little work had been done on it, so any small inconsistencies in the FS meant your data was toast.

Sure, keep backups and all that, but just be aware how important a good fsck tool is.

<comment><USER11> There is no fsck for ZFS. Because the ZFS developers at Sun/Oracle believe that ZFS is robust enough to never corrupt (untrue) and in case it does you should have a backup.

I got screwed by ZFS, and I was able to recover the filesystem by learning its on-disk structure and fixing it directly on-disk. Something that a decent fsck tool could do. But no, ZFS never breaks. Go figure.

<comment><USER12> My employer has thousands of large machines with ZFS on them. We've seen corruption happen once, five years ago.

Maybe we've just been really lucky.

<comment><USER13> The idea that you can have corruption and nothing to fix it with already sounds scary enough to me.

Especially for those of us that _don't_ have thousands of machines and can therefor be badly screwed by one issue.

<comment><USER12> Given the way ZFS works, you'll have to elaborate on what an fsck would do that ZFS doesn't automatically do already.

What I find scary is silently corrupt data, something which is a problem for most other filesystems. I've seen ZFS catch and fix that error orders of magnitude more often than I've seen ZFS flake out. If we're talking risk analysis, I feel you're worried about a mouse in the corner, while a starved tiger is hungrily licking its chops while staring at you.

<comment><USER11> I think it's unfortunate that Sun called it 'scrub' instead of 'fsck'. Because the two are largely equivalent in functionality (to the extents supported by the filesystem). Both fix filesystem corruption if they can. Just scrub can be run while the filesystem is mounted, whereas the traditional fsck must be run when the filesystem is offline.

However, scrub does not make ZFS perfect. There are still ways the filesystem can become corrupted without scrub noticing. Or corrupted in a way so that ZFS fails to recover from, even though recovering would be dead simple.

The attitude of the ZFS developers only works in the enterprise market: Your data is safe (checksummed, scrubbed, replicated using RAID-Z), but if a bit flips in the superblock just restore from your backup, because we won't provide tools to recover from that.

<comment><USER12> While I concur with most of your points, I must point out that there are four uberblocks, not one; a flipped bit will not impair the pool.

Let's argue that bits flip in all four uberblocks though, then ZFS will use the previous valid commit, which also has four uberblocks (ZFS is a CoW FS). And so on backwards for quite a few transactions. All these uberblocks are spread out at the beginning and end of each disk.

ZFS has a policy that the more important the data (and the top of the tree is most important), the more copies there are, although a user can also define how many duplicates there should be at the leaves of the tree.

Basically, you'd need a _very_ trashed disk to render an entire pool dead. You're not going to recover from that, regardless of filesystem.

<comment><USER11> Well, ZFS clearly didn't use the extra copies, nor did it try to use the previous uberbocks. Otherwise it would've been able to mount the filesystem, don't you think? And I disagree that the disk was very trashed, if all it took was to invalidate a few uburblocks to get the filesystem mounted again.

<comment><USER12> Did you use zpool import -F (are you sure)? I'm surprised that'd be necessary though, given my experiences. How long ago was this?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I've used both, and prefer btrfs in terms of implementation. For some reason the use maintenance and control feels more Linux to me. ZFS feels more Unix, which makes sense given the lineage.

The raid arguments against btrfs are silly. Raid 5 is quite unnecessary, particularly with these kinds of file systems. I can only assume people making this argument have never maintained file systems of this type and clearly don't understand how to implement it correctly.

Both ZFS and btrfs are the future though. If admins aren't seriously considering one of the two for thier server infrastructure then they probably shouldn't be admins.

</comment><comment><USER15> Here a study of the evoulution of Linux File Systems (post from 5 days ago): <https://news.ycombinator.com/item?id=5431413>

While it does NOT contain ZFS it is a great read.

</comment><comment><USER16> Why is Oracle investing in Btrfs (GPL), rather than dual-licensing zfs as cddl/GPL?

<comment><USER17> They started it before they acquired Sun.

<comment><USER16> Well, that kind of makes sense in a "we're incredibly lazy" way. But why not license ZFS as GPL, and see if that project makes better headway?

No real cost there, except some possible confusion. Move the developers to whichever project seems to be winning.

</comment></comment></comment><comment><USER18> What about the license compatibility?

<comment><USER19> It looks like very similar issues on the use end to the nvidia binary driver. Can't ship it in Linux but nothing (legally) prevents end users from incorporating it.

<comment><USER20> My concern with the license isn't legal so much as pain of administration. Maybe I'm just old fashion or lazy, but I prefer not to have to check my kernel repo against my kernel module repo to make sure they play nice. It is so much easier when you can just get it as part of the kernel.

That is the reason why I avoid the Nvidia binary driver as well.

<comment><USER21> If you're on Ubuntu, there's an apt package available in ZFS On Linux project's ppa. It downloads the source, builds it against your installed kernel and installs it. Rebuilds on any kernel update. Very handy.

<https://launchpad.net/~zfs-native/+archive/stable>

</comment></comment></comment></comment><comment><USER22> I misread this article title as meaning "ZFS has been backported to Linux 0.6.1". :)

</comment><comment><USER23> What happened - did NetApp waive their patents? Am I missing something? Wasn't the consensus that ZFS is encumbered, and Oracle might or might not defend it, but who knows?

<comment><USER24> If I remember correctly, Sun responded with even more of their own patents at them and eventually they just settled.

</comment></comment><comment><USER25> Lose Interest in ZFS when dev is pretty much stopped. I am looking forward to DragonFly HAMMER 2</comment>


Gross margins and SaaS companies - <AUTHOR> https://twosigmaventures.com/blog/article/why-gross-margins-matter/ <comment><USER2> I've argued that Gross Margin Dollars is more important than Gross Margin percent. Most business school grads are focused on the percent because it's good for the stock price, when it's the gross margin dollars which pays the light bill.

I worked an account where we made 60 points of margin on our base product, which we sold $50M/year. We then sold $100M of an add-on product at 25 points of margin. There were people arguing that we should stop selling the add-on product, until I pointed out that it contributed almost as much margin dollars as our primary, with almost no engineering effort.

<comment><USER3> Why would you ever axe a product that generated $25M, "no effort" or not?

<comment><USER4> Cynical reply... sloppy MBA thinking.

Slightly less cynical reply... it will lead to someone's promotion by writing something like "doubled gross margin percentage by streamlining product lines to focus on core competencies" in an annual review. Sad to say that this happens all the time.

<comment><USER2> I agree.

My theory is that it was partially our MBAs and partially the stock analysts MBAs. In our industry, normal margins were 60 points, so when our company was generating 36 points, it looked wrong to the analysts, so it needed to be fixed....

<comment><USER5> Nothing in my MBA curriculum has taught me that low margins are bad, just that low margins with high capital intensity is bad. At the same time, absolute numbers are critical and should be analyzed independently from margin.

<comment><USER6> I think I don't understand what capital intensity means here. If the margin is low, doesn't it mean that it's capital intensive? In the example, $75M is required to get $25M. Isn't that intensive?

<comment><USER5> Capital intensity has to do with net operating assets (PP&E, working capital). It's capital intensive if you have to build a $1B plant in order to make a 1% margin.

<comment><USER7> ROCE (Return On Capital Employed) is a common measure in capital intensive businesses.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Yet another article that loves to talk about how important gross margin in SaaS is, but tip toes around its definition.

Out of curiosity - how does this audience calculate what is included in the 'cost' / 'cogs' part of the equation?

My take - if the cost is required to _maintain_ the continued ability for the customer to meaningfully use the SaaS application, then it's a COGS. This would mean the following should be typically COGS:

\- Fully loaded infrastructure costs (Hosting / Web Services / sys admin personnel)

\- Support personnel (fully loaded personnel costs)

Also, GM for professional services and SaaS subscriptions should be maintained separately.

If you calculate GM for subscriptions appropriately, you can tell A LOT about profitability or potential for profitability of a SaaS company.

<comment><USER9> We used to calculate gross margins as hosting & other services we paid for to deliver our service and got 85% gross margins.

We recently learned that's not quite right and added in salaries for our support team and site reliability engineers and it's 75% gross margin.

The definition absolutely matters and it would have been great if they stated an opinion.

</comment></comment><comment><USER10> It took me a moment to realize that the plot showing current market capitalization multiples versus gross margin for SaaS companies is _not_ showing earnings multiples, _nor_ EBITDA multiples, _nor_ gross margin multiples for that matter.

That plot is showing _revenue_ multiples ranging from 10x to 50x. In other words, for every dollar of revenues today, it seems shareholders expect many dollars of actual honest-to-good net profits in the future. Alas, many companies on that plot, in fact, reported net losses over the past 12 months.

Let's hope for the sake of these companies, and for the sake of their shareholders, that aggressive spending to fuel growth today ultimately produces future profits that justify those revenue multiples.

<comment><USER11> Agree.

While not an expert, I've tried the regression the author has done with CapitalIQ before. There's a third hidden axis which is whatever you want to define size/maturity/runway to be. That potentially explains some of the lift in multiple as well.

Similarly his example of investors not paying attention to gross margin seems a bit stretched. While I've never personally participated in a venture deal, pre-public private equity investors scrutinize gross margin a lot, and so does equity research converign listed firms.

While conceptually interesting, saying that a 30% EBITDA company that adds 1500 basis points of COGS goes to 15% margins and therefore ROIC falls (or valuation) is relatively boring. But his point about margins persevering post IPO was super interesting. I wonder if for the existing incumbents, after entry of one of these sexy unicorns, gross margin goes down after...

</comment></comment><comment><USER12> The article is useful and worth reading for its analysis, but the title makes me curious: are there people that don't think gross margins matter?

<comment><USER13> Employees (as long as it isn't negative and their job isn't at risk). Customers. Anyone who doesn't own stock.

<comment><USER12> I think those are examples of people that don't care, not people that don't understand.

</comment></comment></comment><comment> zupa-hu The example is so skewed in favor of the article. Why on earth would you spend fixed % of revenues on sales, marketing, R&D, G&A? They add up to 57% of revenues. So, the conclusion of the example could equally be that a SaaS company has to generate 43% gross margins or there is NO WAY for it to make a profit. Come on.. What about Square that is working with 41% gross margins according to the chart above it?

</comment><comment><USER14> So we o my simple mind Gross Margin is the Expected Annual Revenue from a customer, minus "everything but the price paid for acquisition (ie google ads)" \- leaving the per customer acquisition cost as the point the article is making.

I mean, if you have high gross margins then you have low per customer acquisition costs - which has been the whole point of most articles on Saas Slow ramp of death for the last decade.

</comment><comment><USER15> In the top most graph which SaaS companies have gross margins > 90%??!

</comment><comment><USER16> Gross MARGIN Matters... Gross MARGINS might describe an issue of Hustler in a 1980s frat house...</comment>


Git Tutorials and Training - <AUTHOR> https://www.atlassian.com/git

<comment><USER2> Can anyone here comment on atlassian's stash vs github's enterprise offering? It seems nice to have jira integration while github is clearly very popular in the open source world.

<comment><USER3> Stash is great. We use it at work and it's quite simple yet powerful.

You can set up branch permissions, require at least one approval before merging pull requests, one Bamboo build to pass etc.

Since JIRA 6.1 (I think) you can branch from within JIRA, if it's wired up to Stash. (Although this might be any Git repository.)

<comment><USER4> Yap, branching from within Jira 6.1 is great. With the OnDemand suite this all just works flawlessly too!

</comment></comment></comment><comment><USER5> I can't recommend Githug highly enough for learning git: [https://github.com/Gazler/githug](https://github.com/Gazler/githug)

</comment><comment><USER6> I'm not digging their increasing emphasis on git.

<comment><USER7> Why not?

<comment><USER6> Because I use Mercurial. They're going to wind up sacrificing their Mercurial business, where they're the market leader, in order to play second fiddle to github.

I love their stuff and have used bitbucket since prior to the acquisition, and I respect that they may have to do this for business reasons, but that doesn't mean I have to like it.

<comment><USER8> I wouldn't be surprised if their Mercurial business is stagnating because, let's face it, Git has won. With that in mind, it might not be such a bad thing if they sacrifice a market of shrinking value.

<comment><USER9> Git currently has a greater mindshare than mercurial, specially on HN and many open source circles. I don't think that is enough to consider that "git has won". There are big projects and big companies that use mercurial instead of git (e.g. Mozilla, Python, Facebook). Both git and mercurial are great and both can (and probably will) coexist for the foreseeable future.

If you only read proggit or HN you could think that everybody uses git. The reality is that there are many teams that use mercurial. There are many, many teams that are still using old style non distributed VCS. There are lots of teams that don't even use any VCS at all!

There are lots of people (myself included) who consider that git is needlessly complex, and that mercurial hits a better trade off between power and complexity. A lot of teams would be much better served by using mercurial instead of git. I know for example of several HW design teams that decided to use mercurial because they found it much easier to use.

In addition, I don't think that git or mercurial, as they currently stand, are the best we can do on a DVCS. There are plenty of areas where they both can improve (submodules / subrepos being one of them, but also better support for code review workflows, simpler / safer history rewriting, etc). Perhaps something else will come that will learn from git's and mercurial's mistakes and improve on what they offer?

What I mean by this small rant is that it would be foolish to consider that git has "won" and that there is nothing that can come and improve on it. I hope that the git devs don't think that way. I know that the mercurial devs definitely don't think that way, given the number of cool things that they are working on (e.g. with the evolve extension being my preferred one).

<comment><USER10> I'm in the same boat (I use git a lot at work because I work with the linux kernel but I prefer Mercurial for my own projects) but I feel the thing that may end up killing mercurial is git's superior branch support.

For local dev branches mercurial patch queues work great but working with multiple remote branches becomes a bit of a head ache. Generally you end up using several repositories instead of branches within the same repository.

That being said that was the state of the art a few years ago and I haven't followed Mercurial development closely so maybe it's not the recommended way of dealing with that anymore. Is there a way to properly delete a branch in mercurial these days?

Git branches is the only thing I could imagine a git user miss when switching to mercurial. And possibly staging, it's sometimes convenient (but can be emulated using extensions).

</comment></comment></comment></comment></comment></comment><comment><USER11> I find [http://gitimmersion.com/](http://gitimmersion.com/) to be a better hands-on guide to learning Git. Very useful for beginners.

</comment><comment><USER12> What would be really existing is a venture that aims to teach Git to a "niche" like writers, liberal-arts students or an area outside that of programming.

I think that could be pretty exciting. They could basically do it without mentioning Git overmuch.

<comment><USER13> That's kind of what I'm trying to do with a project I'm working on [1]. Everything is backed by git repositories, and the interface allows you to work with git (branch, commit, fork, merge, etc) without actually knowing any git commands. Essentially, git is masked beneath the surface, but you get all of the power of git for versioning and collaborating.

[1] [http://www.penflip.com](http://www.penflip.com)

</comment></comment><comment><USER14> Nice clean, simple overviews on the different git workflows.

</comment><comment><USER15> I'm getting invalid certificate.</comment>


Cent.Co: Upvote with Ethereum - <AUTHOR> https://beta.cent.co/ <comment><USER2> Hey! I'm one of the cofounders of Cent. That link goes to the beta app which lets you earn Ether (the currency powering Ethereum) by responding to questions. You can also ask a question, provided you put a bounty on it.

Happy for any questions or feedback - we just launched Tuesday!

<comment><USER3> Recommend you identify in some way other than showing the age of the question which ones are past the answer bounty stage. Also, I think the questioner should set the lifespan, and it should be related to the amount of bounty offered - i.e. higher bounty allows a longer lifespan, (hopefully) soliciting a better reasoned response.

<comment><USER4> Yeah, looking at the stackoverflow model would be good.

It's also worth noting that the anonymous nature of this will probably drive down engagement. Look at Quora, people use it solely to build their personal brand.

Right now people would answer on cent solely for the money.

Let them do both so you can appeal to a broader market.

</comment></comment></comment><comment><USER5> Hey guys - cofounder/CEO here. Happy to answer any and all questions about the service. I'm seeing a lot of talk of microtransactions, but really microtransactions are not the core of the model. The core is the giving and receiving of actual value as opposed to imaginary value that other networks provide. That said, I do generally believe in the concept of microtransactions and believe we will see more and better products that utilize them now that things like Ethereum are maturing.

</comment><comment><USER6> I think failures of BitcoinTip and flattr and later relative failure of Steem.it shows that there is really no market for micropayments for content.

But what do I do know, maybe ethereum is different.

<comment><USER7> I think it has been quite obvious for very long time that in general there is no market for micropayments/microtransactions. I don't see why on earth someone would be willing to make small transactions all the time. Normal people prefer doing less transactions than more. That's why subscription services are popular.

<comment><USER5> CEO here. It's not that micro-transactions will replace macro-transactions, but that micro-transactions provide a new type of behavior for people to choose from. Rather than give a value that is network-specific (like a "like"), you give and receive currencies that have actual value outside of the network you are in.

</comment></comment></comment><comment><USER8> I think it's cool, despite Hacker News' general bearish outlook on cryptocurrencies. +1 for not issuing your own tokens via ICO and using ETH instead.

</comment><comment><USER9> Why pay when quora is free?

<comment><USER10> Why answer on quora if you can get paid on cent? (assuming it ever gets any traction)

<comment><USER11> The most valuable answers I've seen on Quora were typically written by people who don't need (and probably wouldn't notice) small tipped amounts.

<comment><USER12> True, it's like if someone helps you with a favor, say helping you to move, then you turn around and offer them three bucks for their help, you're likely to get a rather negative reaction. Small tips are really not going to provide any more incentive for people who can provide valuable answers. But I'd love a way to attract attention to questions even if it meant having to put up significant money. Stack Overflow sort of does this with the reputation bounties.</comment></comment></comment></comment>


The Future of the Operating System: Revisited, Part 1 - <AUTHOR> https://blog.webb.page/2019/future-of-the-operating-system-revisited-i <comment><USER2> My long term bet: computing will move towards an interface driven by "emoji as command". Custom iconography will fade out as the interoperability (and familiarity) of popular unicode symbols becomes dominant. So much of the existing textual input we use is designed to overcome the limitations of our software. In the future if you want to go home then you'll ⌂. If you want to go to the supermarket then you'll U+1F6D2. Once the AI knows your usual supermarket then that's where it will bring you. A complete shorthand for interpersonal communication will spring up, obviating the need to express the kind of nuance that we use presently solely to delude ourselves that we have something to say that can't be statistically derived from the total sum of former human communication.

Meanwhile I'll be in my sweet, sweet grave.

Edit: looks like HN can't show the shopping trolley

<comment><USER3> In the 80s a pundit predicted that in the future the interface to spreadsheets would be a games controller, because that's what the kids were growing up with and would want to use when they grew up. Then 10 years ago it was txt shrt abrvs wr t ftr. Except actually they were just the product of now ridiculously dated numeric keypad input the kids of today know nothing about.

The latest kids craze is always the wave of the future, except actually it's usually just a craze and will end up looking just as dated as the Rubik's Cube.

<comment><USER4> It's a thought worth considering though. Basically you have your fingers at the "home row" at all times, so no delay or errors from travel. Also you have analog input instead of digital!

I'd say that the market have optimized creativly the gamepads to near 1:1 through put w/o having to think about backwards compatility.

What holds us back is the vast majority of minimum effort pencil pushers who want to spend 8 hours at work and don't care if things get done. They would never see the idea of making their job go faster say by a better keyboard and or by writing a nifty script to automate some dull toil. As long as they have a legally protected job they'll just go there 8 hours a day and don't care if they are doing something that could be automated in an hour!

</comment></comment></comment><comment><USER5> Is my scrollwheel broken? Oh, no, somebody just abused Javascript events for a horizontal scroll.

<comment><USER6> The scrolling is so horrible on this page. Only way I can move forward (right) is by scrolling up and one full swipe on my track pad moves it ~200 pixels.

<comment><USER7> I had the same experience, but I found that the arrow keys worked fairly well for moving side-to-side. The presence of a workaround still doesn't make this kind of thing acceptable though.

<comment><USER8> I'm a fan of multi-column layouts horizontal scrolling but this one is badly done. The scrolling speed is wrong; might be calibrated for the author's pointer device, because they vary a lot, both among devices and among operative systems. There is no way to get it right.

The mapping of vertical scroll to horizontal scroll is something that should be done by the browser when using a multi-column layout.

My most recent attempt is this: [https://sentido- labs.com/en/library/201904240732/Xanadu%20Hy...](https://sentido- labs.com/en/library/201904240732/Xanadu%20Hypertext%20Documents.html)

Right after the title there is a checkbox, checked by default, that when unchecked will lay the document out with multi-column chapters and horizontal scroll inside a chapter, vertical scroll to move between chapters.

I use a touchpad which allows horizontal scrolling so there is no need to remap v-scroll to h-scroll, but that would not work with most mice that only have a plain scroll wheel.

In practice, I too find the cursor keys (also try page-up/-down) the most comfortable way. It's still jankier than it should but I hope that browsers' handling of CSS scroll snap points will improve.

Although the multi-column layout works well for me, it does not for most people because of limitations in both the browser and their input devices, so I had to make single-column the default.

</comment></comment></comment></comment><comment><USER9> We want to send a spaceship to the moon but we haven't even made a decent car yet.

There is not a single good desktop operating system. Am I the only one that has noticed this? I hope not.

Windows sucks, Linux distros suck, MacOS sucks, but each one sucks in a different way. Our whole civilization depends on desktop computers, and they run crappy software. I wonder how haven't we all died because of the unreliability of our software stack.

I don't care about weird mobile things that are always connected to my watch running javascript. I want a computer --a regular, personal computer-- that works well, looks decently good, with a nice user interface and that doesn't spy on me. Is that too much to ask?

<comment><USER10> I wholeheartedly agree. While the technical underpinnings of today's desktop operating systems have never been better (we have come a long way from DOS- based Windows and the somewhat unstable classic Mac OS), I feel that we have experienced a decline in the user experience.

I personally believe that Windows 2000 was the best version of Windows despite its security issues. Windows 10 is technically better, especially with its Windows Subsystem for Linux layer, but unfortunately Windows 10 doesn't support Classic Mode like earlier versions of Windows, and I find Windows 10's telemetry, advertising, notifications, and mandatory updates highly annoying. Windows would be a great OS if it weren't for its annoyances, which is why I hope that one day ReactOS catches up with Windows 10 in terms of compatibility.

I personally love macOS, but its EULA ties it to Apple hardware, which I've become increasingly disappointed with. And, quite frankly, I have a soft spot for the simplicity and consistency of the classic Mac OS, even if its architecture needed a complete re-haul.

As for desktop Linux, while it definitely has all of the components necessary for a modern OS, it lacks the fit-and-finish that macOS has. Part of it is due to the very nature of the development of desktop Linux. Unlike Windows and macOS where Microsoft and Apple, respectively, have control of the entire stack from the kernel all the way to bundled applications like WordPad, Edge, and Safari, in desktop Linux each component is part of a completely different project that is made by different developer teams who have very different goals, which are often not aligned with a larger vision of providing a coherent desktop experience. Now, one can find greater consistency by sticking to applications that follow the GNOME and KDE user guidelines. However, many applications don't follow either one of these guidelines. I find that Linux distributions have the uphill battle of trying to create a consistent, coherent environment out of a collection of discrete, disparate parts. The result is a system that may very well be just as full-featured as Windows and macOS, but it feels more like a collection of parts rather than one coherent system, which becomes apparent whenever something breaks.

I would love to use a desktop operating system that provides coherency and consistency while also allowing the user to have full control over his or her environment. I also want to use a desktop OS that is also unabashedly and unashamedly a desktop OS and not one that tries to integrate a user experience that is more suited to mobile devices rather than desktop computers.

Unfortunately operating systems are very capital-intensive to build. This blog post ([http://mmcthrow-musings.blogspot.com/2019/06/my-2019-mac- pro...](http://mmcthrow-musings.blogspot.com/2019/06/my-2019-mac-pro- disappointment-and.html)) contains more information about what it would take to build the type of system that I would love to migrate to.

</comment></comment><comment><USER11> I disagree with the article's conclusion. I think the reason the desktop metaphor with files and folders has stuck around so long is because it is actually a pretty good, and neatly simple, abstraction of how things actually are.

<comment><USER12> Every new OS, it seems - mobile or desktop - seems to go out of its way to hide my files from me. On Windows 10, the "C" drive isn't listed until you go one level deep.

</comment></comment><comment><USER13> Unpopular idea of mine (not invented by me oc): Horizontal scrolling is a great idea. The only reason it is annoying in this site is because there is no first class support for it in many touchpads and physical mouses.

<comment><USER14> if you're talking about paragraphs: DEAR GOD NO.

Paragraphs should be 40-80 ems wide if you want them to be readable. My phone has first class support for horizontal scrolling and it still sucks.

Now if you're just talking about window management then yes I totally agree with you (See X11 "pagers" (a different approach to "workspaces") that are part of FVWM and TWM.)

Edit: I should probably include an argument instead of just an opinion: obviously scrolling is a necessity, you can't fit all the information you want on one screen and paging is (IMO) generally worse. When you're reading a document or paragraph you're concerned about context. Really scrolling here in general is bad but you're moving left and right so often enough that it makes the most sense to just wrap text and have vertical scrolling (with an image the scrolling direction really doesn't matter it just sucks in general.) switching windows (or whatever) usually indicates some kind of mental context switch (looking at a different source file, looking at build errors, etc.) and so it doesn't matter so much if you have to scroll (Although you'd naturally try to keep things with shared context close, preferably within one physical screen of each other, because no scrolling is still always better.)

<comment><USER15> I think the idea is to have multiple columns on screen (like some print magazine and newspaper layouts) so each paragraph is still 40-80em like you say, but you just see more of them at once. (this was roughly the Windows 8 layout guidance)

</comment></comment></comment><comment><USER4> Why not go closer to the UNIX abstractions but with modern graphics and utilities instead of away from it. So in essence the commands and structures of UNIX files (nodes) and directory structures (graphs) but presented via state of the art visualization methods?

</comment><comment><USER16> What's with the bizarre horizontal scrolling?

<comment><USER17> Bizarre and _flaky_. Couldn't read. Apparently the author is an advocate for responsive design (as though that had anything to do with operating systems). I guess thwarting the user is a kind of response.

<comment><USER18> the mobile experience is fine, but opening an image for a closer look won't save your scrolling position when you get back

</comment></comment></comment><comment><USER19> If you look at how far a regular user could get in the 90s with Applescript, Hypercard, and the Classic Mac OS, today's systems are quite underwhelming by comparison.

I have no doubt that all the Unix based systems of today are more stable and faster than the older (and more diverse) crop of personal computing operating systems, but these systems lack the kind of true computing power that older systems provided to regular users.

Smalltalk systems are another kind of vision for what a personal computing operating system could be like: no "applications" or "files," just a sea of computing structures called objects and levels of metaphor and abstraction that give regular users powerful ways to interact with them.

Today if users want to go just a step beyond what their shrnkwrapped programs can do -- and trust me, that happens all the time -- they have two options: either buy some plugin or other program that hopefully does the job, or learn a full-fledged general programming language from the ground up and then apply it to the problem. That's pretty sad -- doubly sad, considering the core metaphor of most operating systems today is a teletype!

</comment><comment><USER20> The UI of this article seems to break my browser. The horizontal scrolling only gets about as far as the terminal UI image and then stalls out. Can't pan further right. It made me think "The future of the OS is trying to do c. 1986-ish basic mouse controls."

</comment><comment><USER21> Although referred to as a joke, I really like the look of eDEX-UI, and I look forward to trying it out. I have a tablet running Ubuntu which I mostly use for writing and freehand drawing, and it'd be nice to use it for other things (particularly terminal based programs) without having to attach peripherals to make the UI usable.

</comment><comment><USER22> Nice mini write up. Author, if you hear me, you either use a dot grid as a background AND you align text and images to it, or you don't use the dot grid background. My OCD was killing me.

</comment><comment><USER23> "Toggle Reader View" -> Much better experience.</comment>


Linus on keeping a clean git history (2009) - <AUTHOR> http://firstname.lastname@example.com/msg39091.html <comment><USER2> This highlights the only thing I don't like about Git. It's an immensely capable tool, but it gives no guidance regarding the _right_ way to do things.

Our own teams have a set of practices which are similar but different from what Linus outlines here. And different projects on my company use different practices from those.

The worst thing is that there's no way of enforcing these workflows or practices other than out-of-band social conventions. And so minor mistakes happen, all the time. Our Git projects are never as pretty as they should be.

In other words, Git provides an awesome set of primitives for source control. I'm not sure what it'd look like, but I'd like to see a product that built on those primitives to enforce a little more order on projects.

<comment><USER3> On a repo I've been maintaining, I'm horribly tempted to revoke almost everyone's commit access, for two reasons: to add a code review step to the process, and to be able to keep the commit history reasonably clean.

It's low-tech, but a human gatekeeper's really your only hope for enforcing whatever conventions your project has.

<comment><USER4> Based on what I've seen from popular open-source Python projects I've used in the past (Fabric, Haystack and basically anything else by daniel lindsley) having a _single_ human gatekeeper is the express lane to hell. If you do that make sure you have at least a few core contribs who can approve commits.

<comment><USER5> Linus is the single gatekeeper of Linux.

<comment><USER6> No, he isn't. He's the final gatekeeper but there are several of lower level gatekeepers/maintainers for different parts.

At least according to rumors, I've never invested the time to get involved myself.

<comment><USER7> There are an awful lot of maintainers for smaller individual pieces/subsytems of the kernel. Take a look at the MAINTAINERS file to see who is responsible for the smaller chunks:

      grep -B1 ^M: /usr/src/linux-kernel/MAINTAINERS

</comment></comment></comment></comment></comment></comment><comment><USER4> Like lukev said, git is "an awesome set of primitives". How you build a workflow out of those primitives isn't set in stone (though, like most things, Linus has strong opinions on exactly how to use his products). This is basically what Github has done, with an extra layer of UI glitz, social, and (much-improved) notifications.

That said, IMO there is still quite a lot of room for customization in git workflow when using Github. For example, we don't "send patches around" as Linus says. Our private feature branches live on Github but we've adopted the convention that the "private" branch name is prefixed by who's working on it, e.g. mdeboard-oauth, jschmoe-url-routes. If it has someone's name at the front, don't touch it. That enables us to still use the "D" in DVCS while retaining the ability to safely rebase our own work to keep our history clean.

The only reason I'd want a git-based product to "enforce order" is a culture- related one: ensure that contributors/collaborators do things in line with the conventions we've established. However, IMO it's always better to have a conversation about that than work with an overly prescriptive tool.

</comment><comment><USER8> I'm still new-ish to git and don't get why rebase is popular. If I do my work on a branch B, I can merge this branch into the master M. The merge point will have a succinct message "Bug Fix #1". You can print the history so it only shows these merge messages and not the messy history in the branches. Isn't this the same as rebase? That is, rebase _removes_ the messy branch history. But I'd prefer to keep that history, but rarely use or display it. bisect can also ignore those branches and only use the merge points. Saving the branch history shouldn't be problem. What am I missing?

<comment><USER9> There are two major things I really gain out of rebasing frequently.

Firstly and most importantly, Thanks to rebase I'm constantly working against the most recent mainline, merge pains are reduced by frequently dealing with smaller rebase merges instead of trying to do one massive merge at the end when I'm finished with a longer life task that might last a week or two. The more often you merge the less painful it is.

Secondly there's the cleaning part of history involving squashing. I believe the issue with your viewing the merge history of the main line will miss out on changes that were able to be introduced fastforward without a merge. And frankly no one else on the team cares that I committed 6 times in the process of one task, they want to see all the code relevant to that task, and ideally it's all in one change set.

There's a pretty reasonable summary over here <http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/>

For certain teams rebase just makes a lot of sense.

<comment><USER10> > merge pains are reduced by frequently dealing with smaller rebase merges > instead of trying to do one massive merge at the end when I'm finished with > a longer life task that might last a week or two. The more often you merge > the less painful it is.

You can take care of that just by doing frequent regular merges, no need to do rebase ever, and rebase doesn't make this part any easier, does it?

I think the 'cleaning part of history', and trying to avoid those annoying merge commits in the logs, is in fact the only reason to do rebases, no? It's obviously an important one to many people.

</comment></comment></comment><comment><USER11> So I'm relatively new to version control entirely, but in the last few years my group has been making a big push to institute Git. I have been wondering lately, however: how much history cleaning is expected/desirable?

When I develop, I split my commits into as many small changes as I can so that the commit messages are single topic. I thought that was basically the idea. Every once in a while I use rebase to combine a few commits that should have been done together as they all addressed the same issue. This all seems right to me. I am left with a clean history of everything I have done on a very fine grained time scale. But the large number of commits, each with little significance to whole program hides the large scale structure of the development.

However, I could use rebase to start combining loosely related commits, trading the time resolution for clarity in the commit history. There seems to be a continuum along this scale. Where is the proper place in that continuum to say this is clean enough? Also, I don't like making changes where I am losing perfectly good information.

I know that I can group certain commits by defining a branch, developing on it, then merging (non-fast-forward) back to the original. The branch should keep the grouping in the commit history. I even suppose that this is can be done after the fact using rebase with the proper amount of git-fu. Is branching and non-fast-forward merges the preferred method of grouping related commits in the history?

If so, this seems troubling as it means that partially fixing something is difficult to do with a clean history. Until the piece of the program you wish to fix is completely working, it shouldn't be merged into master because it would ruin the grouping of the related commits. This means that there can't be any partial thought's like fixing bugs as you find them, because presumably you might want to group all bug fixes of a function together, but have a distinct commit for each.

Now I'm more confused than when I started. Seriously, any references or advice on this sort of topic are welcome.

<comment><USER12> > However, I could use rebase to start combining loosely related commits, > trading the time resolution for clarity in the commit history.

In general, your commits should be the smallest atomic operation that makes sense. When people talk about 'clean history,' they're talking about working in the awesome workflow git provides:

1\. Write half-written broken code. 2\. Fix that code up. 3\. Add some more onto that. 4\. Fix a typo! 5\. Forgot to update the README.

Now, you _could_ push that to master, but then the main master is littered with commit messages like 'oops' and 'typo.' Instead, you can rebase 5-1 onto the latest master, squash them together, and have one 'nice' commit that only has the cleaned up final changes.

This is one of the most powerful things about git: in a private repo, you can commit all kinds of garbage and half-written stuff without caring. When you want to make your stuff public, rebase and squash, then send it out. Be careful though! Only rebase your own private branches, or you're gonna have a bad time™.

<comment><USER11> Okay, that is basically keeping with my current understanding (though I'm not sure how much I live up to the "only have working history in the public repo" rule).

There is the other issue I raised, however: is there a good way to group a series of commits that happen to be towards a single distinct goal. Using branches is a clear step in that direction, but it seems like a nightmare to perform a rebase like you described if the commits are mixed and I would like the end result to involve grouping via branches. That is confusing, hopefully this will clear it up:

1\. Bugfix in function1. 2. Bugfix in function2. 3. New feature in function2. 4. Bugfix in function1. 5. Bugfix in function2

...and we want in the end:

          /-- 1 ---- 4 ---\
      ---<                 >--HEAD
          \- 2 -- 3 -- 5 -/

Can rebase do this easily? Is this a good idea (it seems like it is to me)? The programmer would have to confirm that the code works at every state.

<comment><USER13> Switching branches is cheap, I'd say the "right" way to get a tree like you want is to have two or even five branches all the time you're working. But I suspect you could make two branches and cherry-pick different sets of commits onto them to get the result you're after. To my mind it wouldn't be worth the effort though; how often do you really care whether the code worked with only 1 and 4 applied?

<comment><USER11> Right, I would say that it isn't worth the effort. Also, I probably never care about the code with only 1 and 4 applied. So perhaps branches aren't the right way to do what I am describing.

I always saw VC as a systematic way to keep a log of my development so that I could figure out where I may have broken my code. For this purpose, having some sort of meta-data where commits can be grouped would be nice. It would also work to do something like always end my commit messages with some kind of meta-data tag that I could grep the log for. I was just wondering if there was a prescribed/built-in way for Git to handle this.

<comment><USER13> git-bisect is the standard tool for figuring out where you broke something. I don't know what it does with branching histories though, I tend to effectively linearise my history by rebasing each branch on the trunk head before merging it.

</comment></comment></comment></comment></comment></comment><comment><USER14> Funny. I was just finishing a chat with a colleague about a git strategy for a coming new release of a production product, then saw this post on top. I've been working on it without collaboration for about half a year now, so thats easy.. I've had mixed experience with both rebasing and pull strategies before that. I've found rebasing being a lot better when working with tightly coupled code. And pull being a lot cleaner in being able to cherry-pick and revert to previous states more easily. rebase is indeed a destroyer.

We've now decided to use this model, while only deleting feature branches after RC acceptance.

<http://nvie.com/posts/a-successful-git-branching-model/>

My colleague just suggested to rebase regularly from the develop branch while developing features "I'm working on a branch. someone - e.g. you - updates the develop branch. I will have no info if that is related to my stuff or not so, I should rebase regularly to the latest version of the develop branch"

I'm kinda clueless now. Git is really powerful and flexible in strageties, and that adds to complexity.

</comment><comment><USER15> here's a more recent rant: [https://github.com/torvalds/linux/pull/17#issuecomment-56599...](https://github.com/torvalds/linux/pull/17#issuecomment-5659933)

</comment><comment><USER10> oh yeah, perfectly straightforward, only took several thousand words to confusingly explain.

Nope, not simple. Yep, this is a git usability problem.

In the ruby/github world, people generally violate this and DO rewrite 'public' history in order to get 'cleanness', primarily because almost ALL history is 'public', since you tend to show people work in progress on github, or just push it there to have a reliable copy in the cloud. And yes, this sometimes leads to madness.

</comment><comment><USER16> Unintentional contradiction two messages down the thread: Linus says "But note: none of these rules should be absolutely black-and-white. Nothing in life ever is."

Or perhaps intentional. I can never tell when I read a Linus fiat.

[http://www.mail-archive.com/dri- firstname.lastname@example.com/...](http://www.mail-archive.com/dri- email@example.com/msg39094.html)

</comment><comment><USER17> git is so overly complex (Coming from svn).

<comment><USER18> I think that for people with an svn background there are three different issues that all hit at once:

* distributed rather than centralised version control brings a new set of concepts to understand

* git is flexible enough to support many different workflows. This means you have to actually _choose_ one, and choice is difficult especially when you're just trying to get to grips with a new tool. svn has much more of a "one standard way to do it" approach

* git's UI is in places confusing, inconsistent and occasionally just randomly and unnecessarily different from most other version control systems

The first two are 'essential complexity'; the third is more 'accidental complexity'. In any case I feel it's having to deal with all three sources of confusion that makes the svn->git transition tricky for many people.

<comment><USER17> Don't most people actually end up using git in a centralised manner though? eg the rise of github.

I can totally see git is ridiculously powerful, and general purpose. I just wish it'd default to what most people want a bit more.

<comment><USER19> "Distributed" is not the same as "ad hoc". In virtually all workflows, whether using distributed or centralized RCS, there will be a master copy. The difference between distributed and centralized is whether that master copy is the _only_ copy.

</comment></comment></comment></comment><comment><USER20> git needs a "git propaganda" command. Instead of changing history, it would tell it in a different manner.

</comment><comment><USER21> I've heard some of these words...

</comment><comment><USER22> I have tried to get git, some people say one project per repo (which seems crazy but I did it), many projects are ok, you do need a main master repo, you don't need one, then there's the half dozen commands where with SVN it's one.

Now the most valuable thing to me in source control, history, I'm supposed to keep clean? That's like a sacred cow, you _don't_ mess with history.

>> That's fairly straightforward, no?

No _Linus_ it isn't. Git is hard to get right. If it wasn't for EGit I'd be lost. I tried Canonical's bzr and it is more understandable for ordinary humans.

All that aside I really like Linux. :)

<comment> klj613-- Best way to learn git is in the command line (get away from any GUI). And then play with repositories to see what the commands actually do.

"Don't mess with history"? I don't have to commit to my commits as long as my commits ain't public.

Rewriting history is a lie? Well, if you want to keep everything you do in history, maybe commit on each keystroke? That's insane.

Don't commit unless your ready to commit? Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

<comment><USER22> >> Best way to learn git is in the command line (get away from any GUI).

I've used a lot of source control systems and the best always have a GUI and so guess what? I want a GUI unless the CLI for such system is inherently intuitive which if you read my comments I do not think git is intuitive at all.

>> I don't have to commit to my commits as long as my commits ain't public.

Huh?!?! I don't get that, it like makes no sense to me whatsoever. Why do you think I should even try to comprehend it?

>> Don't commit unless your ready to commit?

Are you suggesting I said or asked that??? Are you advising me? Seriously what?

>> Then that be hard to keep track of. Come time to commit you've got 50+ files modified good luck at doing decent commit messages.

Huh? I'm sorry is that English because it doesn't even make sense at all to me? Is it 50 lines changed all clearly related? Is it 50 totally different changes?

<comment> klj613-- Personally I think its better using the CLI for git.

I commit very often however I rewrite the commits. In other words, I mess with my history and it is a good thing (My commits ain't final, in other words... "I do not commit to my commits").

In SVN I try not to commit too often because I do not want to commit (publish) changes which I may not want to keep.

With git I commit very often in stages. Then I can remove them or change them at a later stage. If I do not do this I will end up with a load of files (e.g. 50+) which has been modified and either I commit them all in one (bad) go or try and separate out each step I've taken the past 12 hours and do decent commit messages (good).

Of course you could commit very often, create new commits to fix errors you've done in recent commits (rather than rewriting history). You could also merge master into feature-x everyday (rather than rebasing), but then you'd have history which looks like chaos and hard to follow.

-

Honestly, when I started git I was lost (first VCS I learnt). Until one day I figured out how simple git is to use.</comment></comment></comment></comment>


Intel Outside as Other Companies Prosper from AI Chips - <AUTHOR> https://www.technologyreview.com/s/601505/intel-outside-as-other-companies-prosper-from-ai-chips/ <comment><USER2> This article is far too optimistic about Intel's future for a headline that reads "Intel Outside".

Besides companies making their own more custom AI chips with higher efficiency, and the recent news that China is building its next 100-petaflops supercomputer, Fujitsu also wants to build its exascale supercomputer on ARMv8 next.

[http://www.theregister.co.uk/2016/06/20/fujitsu_arm_supercom...](http://www.theregister.co.uk/2016/06/20/fujitsu_arm_supercomputer/)</comment>


The Internet interface is dying. - <AUTHOR> http://lighthouseinteger.blogspot.com/2010_05_01_archive.html#5892668337098426531 Please discuss! <comment><USER2>
      What if, in Windows or OS X or linux, whenever you wanted to go to a folder or open a new app, you had to write the name of the folder/app and it's path in the terminal. What a waste of time, right?

Actually, it's the opposite. I have been a fan of Launchy for years and I can't even imagine how I would manage so many applications with icons, or how I could open a program so quickly.

<comment><USER3> I keep my Finder windows in Column view, and usually navigate around by typing (the first few letters of) its name, not dissimilar to how I use the Awesome bar.

</comment></comment><comment><USER4> Actually I find my web sites by typing one or two letters, and awesome bar does the rest.

And it is already possible to put bookmarks to web sites on the desktop.

What is supposed to be the great new replacement for files - a grid of norm sized icons???

<comment><USER5> It's meant to address original findability issues with online apps, not launchability.

The wonderful thing about app stores like android Marietta and the iPhone appstore is not that they add an icon to tour desktop.

The wonderful thing they provide is a unified way to find, compare, purchase and launch apps. Something the web - and web applications - both have been missing for a while. It's the logical extension to Google's mission statement of indexing the world's data.

The only difference is this time it's adding applications to the mix; seeing as the web is slowly (but surely) converging with the desktop, this is actually a bold and brilliant move.

</comment></comment><comment><USER6> The phrase 'is dying' should die. It's not even used in the article itself -- why is it in the title here?

<comment><AUTHOR> You are absolutely right, and I am sorry. I guess this was one of those cases where, if you see something enough, you subconsciously embrace it.

I apologize for the hyperbolic and sensationalistic headline.

<comment><USER7> What I thought the article would be about, though you did touch on it, is how the prevalence of APIs and data-driven, single-purpose apps have begun to put a dent in web access of major sites (social media, shopping, news). It's an interesting phenomenon, definitely something deserving some further examination.

</comment></comment></comment><comment><USER8> I will miss it if it goes. It is one of those concepts I love internet for. Everything is leveled, and all websites are equal in some sense of identification.

</comment><comment><USER9> Except things like Spotlight and search in Windows are great too. For apps you don't use often, it's much easier to find them by name, by task, or tag then by scrolling through a long list of icons. Chrome's omni-bar is exactly that.

<comment><USER10> The dock at the bottom of my OS X screen very rarely gets used, typing the name of an app in quicksilver seems much faster.

<comment><USER11> That's why I advocate the Dock on the left and auto-hide: to recover those previous few pixel rows. I have it shrunk down to the minimum size. It might as well be completely disabled.

</comment></comment></comment><comment><USER12> There's a place for command-line and there's a place for shortcut. It all depends on the number of options in an interface.

If you only need to do a few things in an interface, shortcut is better because it's clean and intuitive. But when you have lots of behaviors (i.e. millions of potential websites to go to), shortcut just doesn't make sense. That's where an auto-completable search command-line becomes useful.

Plus, I rarely see people use the address bar the way it was "meant to be" or the way that the author described it. People either google the website that they want to go to or the address bar auto-complete it before one finished typing.

Even facebook has a global auto-complete search box.

Watch it, when the number of frequently-used apps in an iphone reaches a critical amount, it will make more sense to use app search/run interface.

</comment><comment><USER13> "What's the advantage of "installing" an app from Chrome Web Store? When Google Chrome users "install" a web application from the store, a convenient shortcut is added for quickly accessing the app."

When I read that I say to myself, "wait, you mean a bookmark?"

</comment><comment><USER14> This idea looks so much like the AOL of 1994 (or worse, the MSN of 95) I want to give up an move to the mountains.

The web is a wonderful construct, a thing we should treasure as it makes everybody equal. You can put up a site in a couple minutes, make your web app and put a dent in the universe, and be just a couple keystrokes away from everybody, just like Google.

It's really disappointing when people want so much a nice walled garden to be imprisoned within.

</comment><comment><USER15> How is this different from Site-Specific Browsers like Fluid? <http://www.fluidapp.com/>

</comment><comment><USER16> Imagine if del.icio.us was not bought by Yahoo and instead progressed to where we all thought it would be... Basically, it would serve the same discovery mechanism as app store. You could see what other people were bookmarking and quickly add it to your bookmarks. Discovery problem solved!

(Damn you Yahoo and your inability to do the MERGE in merger & acquisition)

</comment><comment><USER17> The "page" may be less fashionable than the "store" these days but It ain't dying. No one is required to buy what "bundle sellers" are selling.</comment>


Show HN: A podcast app for bookmarking and finding shows via guests - <AUTHOR> https://apps.apple.com/us/app/tl-dl-too-long-didnt-listen/id1483572885 <comment><AUTHOR> Hey HN! I've been working on this app for a while now. I launched on my personal twitter a month ago and it went viral among the tech & VC crowd haha. [http://tldl.app/app](http://tldl.app/app)

The app Too Long; Didn't Listen - is a podcast bookmarking app where you can make bookmarks of _any_ show that's available openly via rss feeds. And you can discover new shows via bookmarks that other people have made.

Podcasts are openly available on RSS feeds, which is great but sadly there hasn't been any fundamental changes to the listening experience and all the podcast apps pretty much look and work the same. So here's my attempt at creating something completely different in the space.

Main features include:

\- You can make bookmarks with a tap of a button.

\- You can follow your friends and other top bookmarkers, it's social.

\- The feed is inspired by tiktok. There are "following" & "featured" categories where you can see some of the best bookmarks and also see bookmarks from the people you're following.

\- there's also a "subscribed" feed where you can see latest episodes from the podcast shows you're following + a grid view similar to pocket casts to see your subscribed shows.

\- Another important feature is you can find new bookmarks via famous people. Ex: you can find all the episodes elon musk was in.

\- You can make bookmarks from your existing podcast apps via the share extension

\- you can also create your own categories

\- oh it also has a very unique app icon ;)

app store link: [https://apps.apple.com/us/app/tl-dl-too-long-didnt- listen/id...](https://apps.apple.com/us/app/tl-dl-too-long-didnt- listen/id1483572885)

here's the original twitter post: [https://twitter.com/vidythatte/status/1280299607021494272](https://twitter.com/vidythatte/status/1280299607021494272)

link to twitter where you can keep track of our future updates: [https://twitter.com/tldldotapp](https://twitter.com/tldldotapp)

Only available on iOS for now, we'll make an android when we raise our seed :)

</comment><comment><USER2> excited to be here :D

</comment><comment><USER2> hi</comment>


Million Song Dataset - commons-tragedy http://millionsongdataset.com/ <comment><AUTHOR> I did my master's thesis (2017) using this dataset. I trained a neural network to predict musical features from the raw audio of the songs.

Unfortunately the 7digital ids were out-of-date, so in order to get access to the audio (30 second clips) I had to email another researcher who'd recently published work using the audio data and politely ask them to rsync me the audio XD

</comment><comment><USER2> For anyone else who was curious about the song selection process:

<quote>

How did you choose the million tracks?

Choosing a million songs is surprisingly challenging. We followed these steps:

1\. Getting the most 'familiar' artists according to The Echo Nest, then downloading as many songs as possible from each of them 2\. Getting the 200 top terms from The Echo Nest, then using each term as a descriptor to find 100 artists, then downloading as many of their songs as possible 3\. Getting the songs and artists from the CAL500 dataset 4\. Getting 'extreme' songs from The Echo Nest search params, e.g. songs with highest energy, lowest energy, tempo, song hotttnesss, ... 5\. A random walk along the similar artists links starting from the 100 most familiar artists

The number of songs was approximately 8950 after step 1), step 3) added around 15000 songs, and we add approx. 500000 songs before starting step 5. For more technical details, see "dataset creation" in the "code" tab.

</quote>[1]

What I really wanted to know was if it was a worldwide-music dataset or a more narrowly focused one. My guess based on the above is that it's mostly English- language music, mostly American - can someone who's worked with the data confirm/deny that?

[1] [http://millionsongdataset.com/faq/#how-did-you-choose- millio...](http://millionsongdataset.com/faq/#how-did-you-choose-million- tracks)

</comment><comment><USER3> I think this Dataset is probably unfortunately most famous for an incredibly flawed but very headlineable attempt, which you've almost certainly seen somewhere, by a group of researchers from AI and related fields (none of which had musical qualifications) to "objectively" determine if music has gotten worse over the decades. As usual, they arrived at the conclusion that it did by computing a vague number ("timbral diversity" and "harmonic complexity") for each song, and then showing a scary graph of that number going down over time.

Not sure what my point is exactly. I guess it's just another reminder of how easy it is to arrive at any conclusion you want using complex algorithms on big data.

<comment><USER4> For virtually any kind of art newer artworks will be on average worse than _surviving_ older artworks: the older artworks have undergone a selection process that weeded out the less popular ones.

This is IMO a more fundamental problem with any comparisons across long time intervals.

<comment><USER5> True for a naive approach, but I'd think looking at the chart toppers for, say, each week would give decently comparable data.

<comment><USER6> I actually did something similar! I wrote a small blog post about it here [https://www.popnalysis.com/blog/lyrics-over- time/](https://www.popnalysis.com/blog/lyrics-over-time/)

But I came to the same conclusion as the op comment. Music can't really be judged by any one metric! But that doesn't mean that you don't gain insight into how music has evolved!

also, I did release my entire lyrics dataset that I scraped (about 500k) for free.

</comment></comment></comment></comment><comment><USER7> I was so excited, until I realized the list hadn't been updated in 8 years... :|

<comment><USER8> Probably still good if you want to practice with machine learning on music.

</comment></comment><comment><USER9> I geolocated the artist list: [https://geocode.xyz/874101666267029,share?export=GeoCluster](https://geocode.xyz/874101666267029,share?export=GeoCluster)

Next up, geoparse all song lyrics and compare those locations to the artists'.

</comment><comment><USER10> That's cool, perhaps also link it from a centralized location like Kaggle? [https://www.kaggle.com/datasets](https://www.kaggle.com/datasets) When I look for datasets, I first go to a place like that.

<comment><USER11> Found this dataset on Kaggle: [https://www.kaggle.com/c/msdchallenge/data](https://www.kaggle.com/c/msdchallenge/data)

</comment></comment><comment><USER12> Used this dataset in a university project to try and predict genre's from a number of features.

[https://medium.com/modeling-music](https://medium.com/modeling-music)

</comment><comment><USER13> In case this is not clear: the dataset does not include the raw audio of the songs, just extracted features.

</comment><comment><USER14> Does this data set have a collection of chords in text? I'd love something like it.

<comment><USER15> The dataset is a bunch of SQLite files, so shouldn't be too tricky to interrogate.

You can get a subset (static.echonest.com/millionsongsubset_full.tar.gz), which is 1.8Gb compressed. The full dataset is 280Gb, and AFAICT, this does _not_ contain the full audio.

There's a script on GitHub from like 8 years ago that apparently can get you the audio (but I would be super-impressed if that actually still works).

You can see a description of one song here: [http://millionsongdataset.com/pages/example-track- descriptio...](http://millionsongdataset.com/pages/example-track-description/)

<comment><USER16> It looks like they have data about many of the individual notes in the song. I wonder if it could be possible to turn that data back into some sort of horrible midi version.</comment></comment></comment>


The 17th-Century Moon Mission That Never Got Off the Ground - <AUTHOR> http://www.atlasobscura.com/articles/john-wilkins-moon-mission <comment><USER2> I sometimes feel bad for some of these forward-thinking people from the past (relative to our time) that we can't share with them what we now know. Surely they would be thrilled to learn what has been discovered since their death. I'm sure future humans will feel the same about us and our absurd theories and ideas.

<comment><USER3> To be fair... Man has never walked on the moon in my lifetime either. I find that sad.

<comment><USER4> Thinking about it, it seems weird that there are not at least some happy robots driving around on the Moon that people could take over for fun.

<comment><USER5> you might think thats a fun idea, but what happens when 4chan decides to draw a giant penis on the moon with rover tracks?

</comment></comment></comment></comment><comment><USER6> If you ever want to meet a genuine old-school Oxford don, the Allan Chapman mentioned in this article is your man. I was lucky enough to have him as my history of science tutor for a few weeks almost twenty years ago. He's still roaming around the place hamming it up [1].

The article reminded me of a lovely passage from an old speech of his, also largely about John Wilkins [2]:

"The other big thing is the method by which these new discoveries had been made. They had not been made in studies. They were not made by the ransacking of ancient texts. Nobody deduced the existence of Nova Scotia. These things were discovered by the very simple process of driving a ship into them. A ship is a form of scientific instrument."

[1] [https://www.youtube.com/watch?v=tzwbI7g0whQ](https://www.youtube.com/watch?v=tzwbI7g0whQ)

[2] [https://www.gresham.ac.uk/lecture/transcript/print/the- jacob...](https://www.gresham.ac.uk/lecture/transcript/print/the-jacobean- space-programme-wings-springs-and-gunpowder-flying-to-the-moon-from/)

</comment><comment><USER7> I'm curious how long he thought the trip might take. The distance was accurately-enough known at the time, and it'd take decades at a walking pace with reasonable breaks.

Another neat-sounding 17th-century work in this vein was by Huygens [https://en.wikipedia.org/wiki/Christiaan_Huygens#Cosmotheoro...](https://en.wikipedia.org/wiki/Christiaan_Huygens#Cosmotheoros) who seems to deserve a higher profile. Unlucky in being so overshadowed by Newton.

</comment><comment><USER8> TIL (or at least confirmed) that the letter 'W' was indeed written as a literal double-U.

<comment><USER9> Enjoyed the difcourfe.</comment></comment>


Student Engineers: Apply to work at 170+ startups with one Common Application - <AUTHOR> http://redeye.firstround.com/2012/12/commonapplication.html <comment><USER2> I've had extensive experience in this market (i.e I've spoken to >1000 student developers) and I think this is the right approach.

From a students perspective most students have close to no-idea what kind of company they want to work for when they graduate and often have a very limited concept of the reality of what working at different companies would involve.

From a startups perspective it's very hard to target students, a typical serious recruitment campaign would cost 6-7 figures to run and is really only an option for companies who are hiring a large number of candidates (as you can ammortize the costs of having presence at careers fairs, etc.) - I would imagine Google spends in the millions if not tens of millions in student recruitment every year.

Most startups aren't Facebook or DropBox. Look at First Round's portfolio page, chances are that as someone who's familiar with the startup scene you still won't recognize most of their consumer facing startups let alone their b2b startups.

Most students will never have heard of these startups. Even if a student cares about the domain of the startup they probably still won't have heard of the startup.

You can't be the candidate's first choice if they've never heard of you. But once you've got their CV and you've decided that you want to go after them you can sell them on your company and make it their first choice.

I'm also willing to bet that most startups would rather hire a stellar engineer with average passion about the domain (but cares about the tech) over someone with stellar passion and average talent.

<comment><USER3> As a student/developer I'm excited about the idea of companies I've never heard of who match my interests approaching me.

I am a little worried though that this could end up like the common app for colleges and I'll become nothing more than an application.

</comment></comment><comment><USER4> I'm not sure how to feel about this.

On the one hand, this is something I have always felt needed to exist. In today's weak job market it's important that we do whatever we can to match talent with openings.

On the other hand, I think startups are the wrong type fo companies for this. If I'm hiring for a small (<50) person company I want to make sure the person wants to work on my particular product and help with my particular vision. This would be great for big tech companies though, where they just need development talent and there is sure to be some internal project/product for which you're a good fit.

<comment><USER5> I disagree.

This is a third approach—and a more public one—than we see from A-H and Greylock to help funnel talent to their portfolio companies. It's intended to serve as a first pass and binning for the company to then look for culture fit and second-round interviews.

This process lets FRC centralize talent and reduce at least some amount of time that founders have to spend on recruiting, at least beyond employees 1-5, mainly coming directly from personal circles.

<comment><USER6> As a recent college grad in CS looking for a leg into the industry, besides the HN monthly "who's hiring" threads, I feel like I'm missing out on probably 95% of potential companies I could work at just by them not using online job boards to recruit from. I feel like having some situation where employers can get a list of candidates in advance can open up opportunities better than my current workflow:

Read email for responses -> check linkedin groups for various languages -> read rss feeds of Dice, Careers 2.0 -> write some cover letter emails, attach resume (with links to github, etc) -> hope for something back.

Having some place to put myself in public view to _possibly_ be contacted first sounds really nice.

</comment></comment></comment><comment><USER7> I think one of the most important differentiation of a traditional company vs 'startup' company is the culture. And in order to understand the culture, you'd have to research each individual company, which this service doesn't seem to offer.

The students may be better served if there was a list of tags/terms for the all the companies so the students can go through them and check/tick the ones they want to apply to. Shotgun mass spam doesn't ensure a cultural fit.

(Should +100 (for how many people in the company) even be an option? Is a company still a startup at that point?)

<comment><USER8> I've done something similar with Sequoia Capital before. You applied with one application at their website and they forwarded it to the startups the were funding. The individual startups then contact you for an interview if your application meets their criteria.

For me personally, hearing back for an initial interview has always been the struggle. This approach broadens the reach of my application and gives me a better chance to demonstrate my skills. Once they've considered my application and contacted me, then the ball is in my court and I can scrutinize the company and culture before replying.

</comment></comment><comment><USER9> I'd love to have something like this. As a student at a small school in Canada it is very hard to make connections in the industry that are often facilitated by larger schools.

<comment><USER6> This is exactly my problem. I live in rural PA, went to a moderately close liberal arts school on a full boat (in reflection, I wish I applied to some bigger name schools like Carnegie Mellon), but now that I have graduated I have 0 contacts in the industry and the career center never has companies contact them about software jobs. So I've just been stuck using online jobs boards and they haven't proved effective yet.

<comment><USER10> Bit late to the thread but in your case, sticking some contact details in your HN profile wouldn't hurt :)

</comment></comment></comment><comment><USER11> For those who missed the links (I know I certainly did): <http://www.university.firstround.com/>

</comment><comment><USER12> I feel I need to comment on a couple topics that really stand out from First Round Capital's approach, but no one appears to be touching on:

Firstly, this is an application to be matched with a company in an investor's portfolio. What makes this is essentially different from just a common app is that interviews and work you do for any of these companies on this list may be shared with the entire community/portfolio, and there will be opportunities to move to a place to a better fit or position after establishing yourself (I have seen this done before, an acquaintance of mine worked for a startup in SF this summer, and at the end of the summer he was offered a full-time position at a different company in the same portfolio after hearing about his prowess as a web developer/designer).

Secondly, this is a beautifully put together application. Not only is it aesthetically pleasing, but the questions give a lot of hints to the applicant about what qualities a startup is looking for in a future worker. For a first time applicant, this is particularly helpful.

I definitely support this approach. It has been done already by KPCB Fellows (a bit like a common app, but with less questions; they ask for a portfolio still, but also ask for the applicant to complete a programming or design problem depending on the iteration of the application), and by a16z (Andreessen Horowitz takes a similar approach where you apply with them and are matched with a company in their portfolio based on fit and need), and by Sequoia Capital, just as feniv mentioned. On a similar note, it's been a particularly hot year for recruitment websites like Readyforce, which did Hacker Tour, and Seelio, a portfolio site that just launched a jobs posting section.

</comment><comment><USER13> The success of this will depend heavily on the people doing the parsing of applications and matching them to the right company. While I like the idea of lowering the barrier for applying for jobs, I cannot help but think that many students will look at this as another opportunity to focus on quantity of applications they send out. Instead, I would rather that students take some time to research and figure out on their own what they want for an internship, rather than just sending out a bunch of applications/resumes.

</comment><comment><USER14> I think this could be valuable for little known startups that have a hard time being seen and will take any decent talent they can get, but for any startup that is sought after, why would I want a candidate that doesn't want to work for my startup specifically? Someone who is open to applying to 170+ startups at once is not someone I want on my team. To produce a great culture, you want to be every single candidates' first choice, not their second or third choice.

</comment><comment><USER15> Would be nice to have one of this for foreign Engineers too.

</comment><comment><USER16> We do the same thing at Stack Overflow Careers. Except it's a lot more companies.

I really like this part: "our Talent Team will review your submission and if you're a fit, we'll follow up directly and connect you with relevant companies". They step in and do the work to connect you with relevant companies which is a great value add opportunity for a VC.

</comment><comment><USER17> Don't do this please. It's the total opposite of what startups actually want applicants to do I guess... If I were a startup CEO, this would be a bad thing, but I'm not, so I don't know what the reality is.

<comment><USER18> If a company signs up for this, how does that reflect their culture? Does it say they're a "top-down" organization which is just looking for intelligent cogs to fit in their machine?

<comment><USER6> If it can filter candidates better than the generic post job opening on craigslist / linkedin / dice / careers 2.0 / ycombinator jobs board / slashdot jobs board / etc, get resumes + a few paragraphs of personalization from candidates, then have to go to their online repos and look at code samples before contacting them then it is probably better than the status quo.

</comment></comment></comment><comment><USER19> Something about this feels predatory

<comment><USER20> Well, there certainly is competition for engineering talent.</comment></comment>


Apple Introduces us to the Smart Bike - <AUTHOR> http://www.patentlyapple.com/patently-apple/2010/08/apple-introduces-us-to-the-smart-bike.html

<comment><USER2> In what way is any of this novel or innovative in ways that normal practitioners in the field couldn't think of ?

My Everytrail.com account does plenty of this, ok it doesn't have a cadence sensor but that's only a bluetooth device away.</comment>


Show HN: MStream – the easiest music streaming server - <AUTHOR> https://mstream.io/about <comment><USER2> Noticed a bunch of these projects recently, great to see

[https://funkwhale.audio/en_US/](https://funkwhale.audio/en_US/)

[https://github.com/epoupon/lms](https://github.com/epoupon/lms)

[https://github.com/aidewoode/black_candy](https://github.com/aidewoode/black_candy)</comment>