OpenBSD on the Microsoft Surface Go 2 - <AUTHOR> https://jcs.org/2020/05/15/surface_go2 <comment><USER2> Also, here's a blog [i] that installs _Debian_ w/ a customized kernel onto a Surface Go.

[i] [https://willem.com/blog/2020-03-09_making-my-own-tablet- os/#...](https://willem.com/blog/2020-03-09_making-my-own-tablet-os/#continue)

<comment><USER3> Looks like the patched kernel is only needed to fix a minor bug in the kernel version OP ended up with. I assume that these issues will eventually be fixed directly in the mainline branch.

Also, not sure why OP didn't boot from the "unofficial" USB image with included firmware, that would probably support WiFi directly and not need a separate wired connection.

</comment></comment><comment><USER4> 6.7 is just around the corner (19th May!) and I can't wait.

</comment><comment><USER5> Love this guy's writeups and his blog in general. I'm interested to know whether he uses the Surface Go as a daily driver.

<comment><USER6> Then perhaps, you'll love his (formerly) podcast even more.

[https://garbage.jcs.org/](https://garbage.jcs.org/)

<comment><USER7> I really wish they would bring this back, was one of the best podcasts I've listened to.

</comment></comment></comment><comment><USER8> > The Surface Pen ... the top eraser button which requires Bluetooth for some > reason.

It lets you launch OneNote from sleep out of pen input ranges, that's the reason.

<comment><USER9> Handy feature. I think their implication was that you can't use it as an eraser either, which is a bummer since no Bluetooth support

<comment><USER10> Indeed

> OpenBSD does not support Bluetooth

Anyone have the story behind that? An explicit desire not to support it or lack of manpower?

<comment><USER11> No one stepped up to write and maintain it.

[https://marc.info/?l=openbsd- misc&m=156519841415403&w=2](https://marc.info/?l=openbsd- misc&m=156519841415403&w=2)

</comment></comment></comment></comment><comment><USER12> every six months I try to install linux on my surface sans-number (between 5 and 6 I guess), find bogus linux kernel, try it out, regret imensely. go back to crapy-but-still-better-than-osx windows 10. then six+ months passes, I somehow forget about all this and repeat.

surface tablets would be a killer machine if I could dual boot linux on it for serious work.

<comment><USER13> Installing this kernel makes it work amazing: [https://github.com/jakeday/linux-surface](https://github.com/jakeday/linux- surface)

<comment><USER14> I'd recommend the actively maintained [https://github.com/linux-surface/linux- surface](https://github.com/linux-surface/linux-surface) instead, which has support for newer Surface devices as well.

<comment><USER12> see this is what i mean.

every kernel has pros and cons. all of them are wonderful until you hit a con.

</comment></comment></comment></comment><comment><USER15> Unsatisfied new user/owner of iPad Pro + keyboard + pen, generally happy OS X user here. Touch screen was the hook (as I dabble in visual arts) but for me this has proven to be a very expensive mistake.

What are the issues/peeves with Surface Go? Is this space (touch screen large form factor mobile computing devices) generally underwhelming or is this simply Apple doing UX RnD on my dime?

<comment><USER16> If you're looking for a general-purpose tablet computer I think the Surface lineup is nearly unparalleled, with some important caveats.

You get a very well built machine with the best aspect ratio (3:2), Win10 tablet mode is decent _and_ you can drop back to full Windows whenever you want. This is a double edged sword - if you get a good tablet interface for a program it's wonderful, but sometimes you're reduced to pecking at the screen for mouse targets in legacy Win32 apps (the pen or cover with trackpad is helpful here).

For me, the ability to run any software I want is worth the rough edges and inconsistency compared to an iPad. I have WSL for local dev with full Linux utilities, real Photoshop, alternate browsers, Steam games, etc. I can install whatever nifty little Windows utilities or tweaks I want, customize the machine exactly as I like it, and I feel like I have lot more ownership over the machine as a result. That flexibility definitely comes with a cost compared to the out-of-the-box experience with an iPad.

As for the Go itself, its a really cute little computer but somewhat underpowered compared to a Surface Pro or Surface Book. I know a couple of people using them as their main computers and the feedback is pretty positive, FWIW.

<comment><USER15> Yes, that's what I was looking for. Thank you.

</comment></comment></comment><comment><USER17> Impressive, given I couldn't even get FreeBSD to boot at all in Hyper-V on Windows 10. I know the article is about OpenBSD, but still.

<comment><USER18> What was the problem?

We ran a large fleet on Hyper-V / Azure.

<comment><USER17> It was a couple of months ago, so I don't recall exactly, but I _think_ I couldn't get it to recognise the hard disk.

Are you using any particular boot settings, and are you using IDE or SCSI (virtual) disks?

<comment><USER18> I think that we use blkvsc and storvsc disks. I think that the former are used for boot.

</comment></comment></comment></comment><comment><USER19> > OpenBSD does not support Bluetooth

hmm...

<comment><USER20> Anymore.

[https://marc.info/?l=openbsd- cvs&m=140511572108715&w=2](https://marc.info/?l=openbsd- cvs&m=140511572108715&w=2)</comment></comment>


Open landings: Community-driven landing pages for open-source projects - <AUTHOR> https://openlandings.com <comment><USER2> Id suggest adding some info/examples/screenshots, to your website.

What can the landing page contain? What does it look like? What options does a user have? All things someone that is interested may want to know before singing up and linking to GitHub.

</comment><comment><USER3> Big report on page linked:

The two "Read more" buttons do not work on android/firefox.

<comment><USER4> They don't work in chrome either.They have no href, data-id, or anything that resemples a location, just class="ui large button", so I'm going to assume this project is just somebody fishing for interest.</comment></comment>


The Principles of Chaos Engineering - <AUTHOR> https://caylent.com/the-principles-of-chaos-engineering <comment><USER2> Like it</comment>


Show HN: Jekyll meets Posterous – Static Blog and Email Posting - <AUTHOR> http://www.utterson.me

<comment><USER2> Nice idea! It think Posterous was awesome and I do miss features like e-mail posting for my current github hosted Jykell blog.</comment>


Run Golang on the Intel Edison with Gobot - <AUTHOR> http://gobot.io/blog/2014/09/24/run-golang-on-the-intel-edison-with-gobot/

<comment><USER2> Thanks for posting!</comment>


Wikia plans editable Web search engine - <AUTHOR> http://www.insidebayarea.com/business/ci_5406665 <comment><USER2> Wow how is this going to work? Being a code monkey it looks like a fun tool to play around with :D but could it really challenge Google?</comment>


UK has best health system in developed world, US analysis concludes - <AUTHOR> http://www.bmj.com/content/358/bmj.j3442 <comment><USER2> This analysis of a report seems pretty bad, even with only the title and abstract available.

Firstly, the report doesn't even cover the entire developed world, just 11 countries. Notably, Japan doesn't appear to be included. To be honest, I found that slightly offensive.

Secondly the U.K. isn't the overall clear "best" of those 11. It's not bad, and does better on some things, worse on others.

In my subjective experience (as a Brit) British people often think the NHS is the best health service in the world. It's not bad, and it's free. Waiting times are often long, particularly for non-urgent conditions. Compared to the U.S. system I prefer the NHS, but there are other options, and the NHS could provide a better service than it does.

<comment><USER3> _In my subjective experience (as a Brit) British people often think the NHS is the best health service in the world_

Having experienced it, I'm surprised that Brits feel that way. When I was studying abroad a while ago (which was not a great experience for other reasons... [https://jakeseliger.com/2012/11/18/about-the-university- of-e...](https://jakeseliger.com/2012/11/18/about-the-university-of-east- anglia-uea-why-you-shouldnt-go/)), I needed an x-ray and then a CT scan for what appeared to be a minor issue. So I went to the clinic and signed up for one, only to discover a week later that an x-ray typically takes 6 - 8 weeks to be done! I asked around and was told to go to Bupa facility ([https://en.wikipedia.org/wiki/Bupa](https://en.wikipedia.org/wiki/Bupa)). To the Brits this seemed like an obvious solution, and paying in cash is in fact a good way to get things done quickly. It turns out that when people have something really wrong with them, the solution is often to just pay out of pocket!

This disabused me of any notion that publicly-provided healthcare is automatically superior.

<comment><USER4> Is it really a big deal to wait 6-8 weeks to get an x-ray for a minor issue? Obviously this is not ideal, but it seems pretty minor compared to the ridiculous stuff we deal with in the US system, especially if you compare to the pre-ACA US system.

<comment><USER5> Actually, I never understood this. Is demand and supply matched and this is just the lag in the system (ie 6-8 weeks remains 6-8 weeks forever) or demand is greater than supply and this number will grow. If it is the former then there doesn't seem to be a cost advantage for the wait. A temporary increase in supply could bring this waiting time to zero with just the cost of 6-8 weeks worth of x-rays outsourced. And then you have a steady state system with zero waiting.

<comment><USER6> In terms of efficiency, you're right. However because people get fed up of waiting and having to put up with their health issues and pay to go private instead, this reduces demand and the cost to the NHS. Think of it as a softer way of rationing access to some kinds of NHS healthcare to only those who don't have the money to pay for private care instead.

<comment><USER2> Or less charitably... they die...

</comment></comment></comment></comment></comment></comment><comment><USER7> As a resident of the UK and a former resident of Switzerland, I can't understand how they came to this conclusion. Don't get me wrong, the NHS is great and the system works much better than in the US, but health care in Switzerland is just on another level.

Before you say "but in the UK it's free" \- considering what I paid for (private, mandatory) insurance in Switzerland, and the National Insurance contribution that gets deducted from my paycheck in the UK, I'm not so sure...

<comment><USER8> I don't think anyone, in the UK at least, thinks the NHS is free. Most people in the UK who describe it as "free" really mean "free at the point of use" (i.e. no invoice after treatment), but that's a bit of a mouth full.

<comment><USER9> It removes an entire department and source of variable from a 'company' that doesn't need it.

Ultimately you aren't going to deny someone coverage based on cost*, they're going to end up in an ER and 'written off' which will then be billed in to everyone else's costs. Worse, the outcome for the individual is often less good and frequently means they will be, overall, more of a burden on society than if they had received proper treatment in an early stage.

Instead, the 'cost' of billing that is 'outsourced' to the government's tax collectors, which are going to be the /very/ last thing removed if ever.

<comment><USER10> _Ultimately you aren 't going to deny someone coverage based on cost_

For acute conditions, yes, but in the American ER they do not treat chronic conditions, like cancer, depression and substance addiction. That's a public health issue.

<comment><USER11> And even for sub-acute thing, for example if you've broken ankle, it needs a surgery to bring your bones together and put a metallic screws and a plate. But the only thing they'll do in ER is put a cast on your leg (for ~$7,000 bill to your insurance). For the surgery you'll need to look for a surgeon yourself (and, there's HUGE shortage of surgeons everywhere in US, seems like the system wants it that way).

Then your surgeon's hospital will pre-agree on the surgery cost with your insurance. If you don't have insurance or money -- welcome to limpers.

</comment></comment></comment></comment></comment><comment><USER12> The report: [http://www.commonwealthfund.org/publications/fund- reports/20...](http://www.commonwealthfund.org/publications/fund- reports/2017/jul/mirror-mirror-international-comparisons-2017)

It ranks the UK 10th out of 11 on "Health Care Outcomes".

<comment><USER13> Good spot. BMJ won't be crowing that one though.

<comment><USER14> They could, because it also points out the UK had the "fastest reduction in deaths amenable to health care in the past decade" i.e. the most improvement in that category.

If you take a look at the raw data, you can see the basis of comparison (four major diseases: heart attack, stroke, breast cancer, colon cancer, + overall mortality data). The biggest outlier for the UK is clearly the cancer survival rate, where it is more than two standard deviations worse than average and this has been known for some time. The underlying reasons are complex, partly social, mostly ones of late diagnosis, partly due to failure to implement good screening programmes; reports on the topic vary in their tendency to blame patients for presenting late or for comorbidity factors, but here's one of the more measured, from 2011: [https://www.kingsfund.org.uk/sites/files/kf/How-to- improve-c...](https://www.kingsfund.org.uk/sites/files/kf/How-to-improve- cancer-survival-Explaining-England-poor-rates-Kings-Fund-June-2011.pdf)

Most tellingly, with breast cancer, a 2008 report suggested that if you remove all the women who die within a year of diagnosis (whose cancers were likely to have been diagnosed at a very advanced stage), then UK survival rates fall into line with the European average. In other words, the UK has a problem with late diagnosis.

Note that the UK also has a better cancer registry. Germany only captures 1% of the population, the UK captures 80%. Unsure whether the OP report has attempted to detect any resulting skew in the statistics.

Bottom line: if the UK improves the five-year cancer survival rate to OECD standards - and note that the data in this report is from 2015 - then it will flip its position in those rankings and totally cement the #1 position overall.

</comment></comment></comment><comment><USER15> One can argue about who is best, but amongst first world countries, it's sadly not hard to figure out the worst.

<comment><USER16> That depends on whether you are rich or poor.

</comment></comment><comment><USER17> As a swede living in London, I was shocked to find the NHS still uses paper prescriptions that are consumed upon use, at least in my limited experience. In Sweden, every prescription I have is digital and tied to my ID, accessible from any pharmacy or hospital in the country and is not necessarily consumed upon use, I can easily reuse it and renew it.

</comment><comment><USER18> Is the abstract really shorted and the author is mentioned but as affiliation it only says "London". They really don't want to know much about the paper before you pay for this paid research.

<comment><USER19> Use sci-hub to avoid paying anything to get full-text PDF.

<comment><USER20> Hey zkms, this reply isn't about the main thread, but bear with me. I happened upon your comment here ([https://news.ycombinator.com/item?id=13454185](https://news.ycombinator.com/item?id=13454185)) asking about the status of Parabix. Granted, that was almost half a year ago, so you may not even remember making the comment. But just in case you're still curious about Parabix, yes it is still very much in development! I've been working on it since about the time you made that comment. The most fully featured application we've built so far is icgrep -- an attempt to rewrite grep from the ground up using Parabix. It's still a bit rough around the edges, but it's usable and exceptionally fast. On large collections of files (10s or hundreds of GBs) it's often orders of magnitude faster than grep, and has more robust Unicode support to boot. We're working on some other pretty neat stuff too, but they aren't quite ready for widespread release yet.

I'll see what I can do about getting our website updated! Thanks for your interest.

</comment></comment></comment><comment><USER21> This really is a matter of what variables you choose to measure.

For example, the US is by far the world leader in medical research spending - 44% of global medical research is spent in the US. (Until recently it was even higher). [1]

On the same note, many nations regulate the price of prescription drugs - drugs where the initial R&D was done in the states. (Yes, drugs are sold at a huge markup, but that's to recoup the huge initial costs of research). In other words, Americans are taking it in the chin to invest in pharmaceutical innovations, which other countries then treat as a public good.

An additional point that's often obscured: there's no purely capitalistic healthcare system in the world. Even pre-Obamacare, the US system was about 46% funded by the government. (As with the US education system, the availability of government funds has massively pushed up prices). [2]

On a personal note - I'm a brit, but I've lived abroad, and the NHS is one of the reasons I'm considering settling abroad long-term. I simply don't trust the organisation as a whole to take care of my health. If you get assigned a good doctor for your condition, you're OK, but I have my own stories (and I've heard many others) of conditions being ignored or misdiagnosed, even after multiple visits.

In contrast, I went to a hospital in Bangkok that was of far higher quality than the average NHS hospital. (Granted, this was a private hospital, but it puts things into perspective). One Israeli friend said that walking into a UK clinic was like walking into a clinic in a third-world country. It's shabby, the wait is long, the bureaucracy is confusing, etc.

Strange as it may sound, I trust a for-profit entity more with my health, because their livelihood directly depends on taking good care of me. The common argument that healthcare can't be a market because of information asymmetry and doctors being in a position of power doesn't wash: the same holds true for other complex services, like auto repair, and the solution is simple: third party reviews. (On the moral argument, about affordability, I think with a truly private healthcare system entrepreneurs would be able to drive the costs down for people on middle-incomes, and only the bottom 15-20% would be reliant on government or charity spending).

[1] [https://www.urmc.rochester.edu/news/story/4233/u.s.-slipping...](https://www.urmc.rochester.edu/news/story/4233/u.s.-slipping- as-global-leader-in-medical-research.aspx)

[2] [https://en.wikipedia.org/wiki/List_of_countries_by_health_ex...](https://en.wikipedia.org/wiki/List_of_countries_by_health_expenditure_covered_by_government)

<comment><USER22> Interesting thought regarding the r&d spending in the US versus the rest of the world and hence subsidizing global health care. I did look at some numbers in a more recent publication [1](page 21) where the latest r&d numbers for both healthcare and biotech are listed. Germany's spending seems to be on average a little less than 1/3 of the US which would make them equal on a per capita level. The UK seems to be a little below those levels. Do you have any data to support your claim?

[1] [https://www.iriweb.org/sites/default/files/2016GlobalR%26DFu...](https://www.iriweb.org/sites/default/files/2016GlobalR%26DFundingForecast_2.pdf)

<comment><USER23> The UK could easily be more efficient/effective on how they spend their R&D dollars (like for healthcare).

And R&D is very hard to compare due to different incentives to categorize R&D depending upon taxation laws and charity institutions.

</comment></comment></comment><comment><USER24> [https://pastebin.com/ibZM0C8Q](https://pastebin.com/ibZM0C8Q)

Some of the data from the Appendix on Equality pulled out. The difference between countries is quite astounding!

</comment><comment><USER25> having had a fair amount of experience of the british healthcare system i find this very hard to believe, ive been treated like shit by them many times, been talked into an operation i didnt really want (i think they were extra keen because its a rare condition) which they then managed to screw up and cripple me.

another little gem is my current insurance claim, i was knocked off my motorbike over a year ago, yet i still havent received a payout from my insurance, id assumed their lawyers were dragging the process out but by this point she has been convicted, my insurance company have been paid by hers but i still havent had anything back, when i asked my lawyer what was holding it up he said it was just one thing they need, they are still awaiting the medical records from my GP which were requested and paid for back in September but despite monthly attempts to get them to send it they still havent done so and every time i try and contact them to ask why im told that the medical secretary isnt in at the moment and only she can deal with it, but they will tell her to call me as soon as she gets back in, i have yet to receive a single call from them.

i could go on to site a ton of other various reports of shit service that i have personally experienced let alone that of others i know. if i was insurable id have taken private medical insurance long ago and still strongly advise any healthy person in the UK to get private medical insurance ASAP, sure its an extra cost no one wants to pay but if you ever do get sick youll be damn glad you have it</comment>


Attention: The social-web IPO window is now closed. - <AUTHOR> http://gigaom.com/2012/07/27/attention-the-social-web-ipo-window-is-now-closed/

<comment><USER2> Am I the only one who thinks this is a good thing? I was getting tired of all the Silicon Valley "social" start-ups. Maybe new start-ups will focus on more important and more valuable products and services.

<comment><USER3> > _more important and more valuable products and services_

Matter of opinion. Communicating and connecting with other people is pretty damn important.

<comment><USER4> That's right. But where are all those startups inventing alternatives to smartphones/iPhones/iPads ? I need a gulp of fresh air in communication.

<comment><USER3> There's more to socializing than the hardware used to do so.. Heartily agreed on the fresh air though - the last thing we need is another netw^H^H^H^H ad platform

</comment></comment></comment></comment><comment><USER5> _> Is Facebook just a moderately successful ad platform?_

That's the direction it's going. I'm not sure that's all it could be.

</comment><comment><USER6> Now?

</comment><comment><USER7> Yammer is so lucky that Microsoft bought them.</comment>


Millennials on Spirit Quests Are Ruining Everything About Ayahuasca - <AUTHOR> https://motherboard.vice.com/en_us/article/78kmvx/millennials-on-spirit-quests-are-ruining-everything-about-ayahuasca <comment><USER2> People who are good with plants can grow anything in climate controlled greenhouses. Some of the orchids and things like staghorn ferns people grow are incredibly delicate. Even some of the mushrooms you buy in the store for a few dollars a pound are very technical to grow. There is no reason this cannot be cultivated in large quantities, and it is just a matter of time.

</comment><comment><USER3> I was born in 1983, I have seen various definitions of what counts as a Millenial, but I think that puts me on the edge of inside the cohort. We/they, whatever, are desperate for a way to define ourselves and find some meaning. Way to much of being told how special we are means a huge group of people are in entry level jobs or just barely starting to cross into the next level and we are trying to figure out how what we are doing is important and find meaning in it. We are special, so it must have meaning we just have to figure out where it is right? We will latch onto anything that seems remotely authentic, yet we can't help but try to change it to suit our needs, because we are special and must be catered too.</comment>


Pijul for Git users - <AUTHOR> https://nest.pijul.com/tae/pijul-for-git-users <comment><USER2> I don't understand what justifies Pijul's existence. While I agree that Git is a complicated monster that takes ages to learn how to use for most people, Pijul does not seem to solve any problems with Git. Instead, it has many problems that Git solves. From a user-perspective, it doesn't even seem like there's much of a difference, despite the (annoying) choice of alternate command verbs (i.e. "record" rather than "add/commit").

It doesn't really seem like the authors fully understand Git, and what problems it solves.

> [...] in Git each commit is related to a parent [...] But in Pijul there's > no timeline and branches are just sets of patches.

To me, that makes Pijul much, _much_ less capable as a version control system. In Git, knowing the commit ID means that you know the _full source tree state_ with the certainty being equal to the risk of a commit ID hash collision.

With just individual, unrelated patches applied in sequence, you have no such guarantee, and no knowledge of the current state of the repository.

Of course, you could add a seperate state tracking system allowing ID's to point to an immutable and unique set of patches in a certain sequence, but doing so just means that you have now implemented features identical to Git, with just a different internal representation (i.e. irrelevant differences for the user).

> [...] And push those changes in whatever order we want

You can do the same in Git (see interactive rebase, cherry-picking, similar). It rewrites the commit IDs in order to maintain the previously mentioned property of representing the state of the repository, but that's an implementation detail.

<comment><USER3> Pijul is based on a different (and much more advanced) algorithm than Git. That doesn't mean it's the perfect tool - just as Git is better than SVN (even though they're based on the same underlying algorithms), Pijul might be the "SVN-like" tool waiting for its own Git...

Edit: having said that, Git isn't perfect either, I'm keeping my fingers crossed for an even better tool!

<comment><USER4> > just as Git is better than SVN (even though they're based on the same > underlying algorithms)

Please explain this. Git is a content-addressable object-store. SVN is not. SVN's architecture uses a diff as the basis for versioning which ties you to a particular diffing system, git uses snapshots and diffs can be generated using any algorithm because they aren't part of the object-store; so what common "underlying algorithms" are you referring to?

<comment><USER3> AFAIK the basic merge algorithm for both Git and SVN is 3-way diff. Pijul instead uses commutative patches and a more complex merge algorithm.

<comment><USER2> Is it a _better_ merge algorithm? Complexity on its own is not a selling point.

And if it is better, then I believe that it should also be possible to implement for Git, as the patch properties of Pijul and Darcs can easily be emulated.

<comment><USER5> 1\. It is associative, which make it predictable, and yes, better.

2\. It is commutative, which makes it non-trivial to emulate with Git, a system where nothing commutes (on purpose).

Of course, you can obviously do your merges manually, rebase the world at each new commit, cherry-pick and rerere to emulate what Pijul gives you for free. But then is your job writing code or showing your proficiency at Git?

</comment></comment></comment></comment></comment></comment><comment><USER6> > Git stores the repository changes as a series of snapshots. That means that > every time we commit changes it keeps a new version of every file that > changed so the size of the repo could grow quickly.

The very first statement in the gtihub page seems to ignore Git packfiles completely for the sake of argument.

[https://git-scm.com/book/en/v2/Git-Internals-Packfiles](https://git- scm.com/book/en/v2/Git-Internals-Packfiles)

<comment><USER7> Their wording is indeed bad, and does not convey at all what they wanted to convey.

Git stores patches to reduce disk size, and does so very effectively. However the same exact patch, applied to a different head has a different commit id. That commit id is a snapshot, even if it is stored as a patch.

Pijul, that same patch applied to different heads, will always have the same hash. This has some advantages that is deeper in their documentation.

Basically, you can cherry-pick changes (patches) from someone else, and then later merge their entire branch, but not conflict on the patches you already imported. Having dealt with this with git, I can see the appeal.

<comment><USER5> > That commit id is a snapshot, even if it is stored as a patch.

I agree with your argument, but Git does store "blobs" only (plus "trees"), and never patches. When you can ask it to show you a diff between two snapshots, Git computes the diff on the fly.

More almost-accurate info here: [https://git-man-page- generator.lokaltog.net/](https://git-man-page-generator.lokaltog.net/)

<comment><USER7> Git does store deltas between files to reduce space. Every so often it stores a full copy of the file to improve performance.

Perhapps patch was the wrong word, but a delta and a patch are the same in my mind.

I am sure everything, including pijul, does diff generation on the fly of the full files at different points. It would be faster than figuring out the difference of patches alone.

<comment><USER8> A packfile delta in Git is arguably an implementation detail — a compression technique — not part of the data model.

Git's data model consists of commits, trees, refs and so on. Not patches. You can implement Git without deltas and it will work the same. But in Pijul, the patch _is_ the data model.

The whole idea of Pijul (and the project it was inspired by, Darcs) is that if you think of patches as units of data that fit together using a kind of formalism (usually called the "theory of patches"), you end up with a very powerful system that makes certain things — solving conflicts, figuring out what commits a single commit depend on — super easy. The patch isn't an implementation detail, because you cannot reimplement Pijul without it.

</comment></comment></comment></comment></comment><comment><USER9> Pijul keeps touting "patches" instead of commits, and they show how to record and unrecord these patches. But how do you actually work with such a repository? How do you handle merge conflicts? The documentation does not even describe how to resolve conflicts, just that you can procrastinate and save the conflicts "for later"[1]. There is probably technical merit in Pijul, but the documentation and marketing sucks.

[1]: [https://pijul.org/manual/conflicts.html](https://pijul.org/manual/conflicts.html)

<comment><USER10> I'm not convinced either. What's the performance of getting the the state 10 versions before? What is exactly the size difference between a git repo and a pijul repo of the same thing?

As for patch vs snapshot, that's arguing at the implementation level. It doesn't affect my use of a tool except as it relates to performance and merging/branching... etc.

Preferring a patch approach rather than a snapshot is like saying map(+)[1,1,1,1,1] != last([1,2,3,4,5]). I don't care.

<comment><USER11> You're right about not caring about the implementation level.

But the difference isn't just at the implementation level, it also relates to merging etc.

See here for an example of how merging works better, by taking into account intermediate commits: [https://tahoe-lafs.org/~zooko/badmerge/concrete-good- semanti...](https://tahoe-lafs.org/~zooko/badmerge/concrete-good- semantics.html)

That is to say, start with version A, on one branch commit versions B1 and then B2, on another branch commit version C1. To merge the two branches (B2 and C1), Git/Subversion etc. will do a three-way merge of "A to B2" and "A to C1". It won't take into account B1 which provides vital information to do a better merge.

<comment><USER10> OK, but if it's needed you could derive patches from snapshots and perform the same steps with a snapshot based VC.

I may be missing something here!

PS less I seem too harsh here, I love looking into version control systems. I have worked with sccs, rcs, arch, larch, bazaar, bzr, bitkeeper, svn and of course git. Looked at darcs very briefly. Never used cvs seriously. Managed to avoid clearcase thank god.

<comment><USER5> Sure, but if you had read the manual[1], you would have learned that this is only the associativity part, which you could indeed use to provide a better merge algorithm in a snapshot-based VCS.

So:

1\. You're 100% correct in saying that this can be done in a snapshot-based VCS like Git, Mercurial or SVN.

2\. But you're also missing the main feature of Pijul, _patch commutation_ , also explained in the manual. The idea is that you don't need to rebase anymore, two patches produced independently always commute, and hence patches don't need to change their identity when they are "rebased", or merged at any point in time. This has major usability benefits, such as being able to undo a "merge" (I prefer to call it a patch application) even after ten other "merges". Or choosing which part of a conflict to remove in order to solve it (if you don't choose to actually solve the conflict). With patch commutation, you don't need `git rerere` anymore, and you don't even need to branch very often, since branch are essentially an emulation of commutation (then of course Pijul still has branches, but they're quite different from Git's branches, in particular they are not as essential as in Git).

But then Pijul is still a young project, there are still a few bugs here and there. It is self-hosted, and we're quite happy using it for its own development (and the development of all companion libraries, Thrussh, Sanakirja…). But is it really ready for HackerNews-level flamewars?

[1] [https://pijul.org/manual/why_pijul.html|the](https://pijul.org/manual/why_pijul.html|the) manual

<comment><USER12> > In Pijul, for any two patches A and B, either A and B commute, (in other > words, A and B can be applied in any order), or A depends on B, or B depends > on A.

This isn't exhaustive. What about the case where both patches A and B are worked on independently, and both depend on an original version of the codebase, let's call it P for parent.

A and B both diverge from P and therefore require a merge, or in git, a rebase. Over my years as a developer this scenario has caused approximately 90% of the issues with git. How does Pijul tackle it?

<comment><USER13> You can simply incorporate both patches A and B, you don't need a separate "merge" step.

If A and B have conflicts, then the resulting repo will have conflicts (but that's allowed in pijul) and you can resolve those conflicts with a third patch, C.

The nice thing is that this patch C can be used to resolve those same set of conflicts, even if someone else has a completely different history. In git, when you perform a rebase, the identity of commits is lost, and so you have to constantly re-resolve the same merge conflicts when merging between branches where one of the branches has been rebased.

<comment><USER11> That sounds great.

What about the situation where A and B don't have conflicts (as defined by the VCS), but still don't work. For example, based on a state of a piece of source code, e.g. A renames a method and all usages (works fine), and B introduces new code (but uses the original method name, also works fine). Merging them will not produce conflicts, but will not work.

In Git I always use "\--exec 'mvn clean test'" when using "git rebase", to compile the source code (which would find such rename issues) and run unit tests (which would find other issues, e.g. A introduces a new mandatory column in a database table and B introduces an INSERT statement without that column).

What would be really cool is if one could say to Pijul "for any operations on this repository, execute this command to determine if the software is OK". And then forget about it. That way all operations it does it could check, and the user could never forget. I wish Git had something like that.

Or have I misunderstood something? I mean, simply relying on "no conflicts implies everything's fine" is not sufficient as far as I can see?

<comment><USER13> I would say that is somewhat outside the jurisdiction of the VCS. Sure you can have post-commit or CI hooks that ensure your code always compiles, but it doesn't need deep support from the VCS to do that.

However, the fact the pijul doesn't really treat the "no conflict" state as "special" is in some ways closer to what you want - the repo is just a collection of patches, and whether the result is "good" or "bad" is not determined by the VCS, but by whatever means you choose to employ.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Why pijul?

Cherry-picking.

In git, cherry picking is broken. In pijul, it isn't.

That's the shortest explanation possible of why a patch-based model is better than a snapshot one. Hope it helps.

</comment><comment><USER15> Not the most important matter but from the FAQs

> Where does the name come from?

> Pijul is the mexican name of Crotophaga sulcirostris, a bird known to do > collaborative nest building.

About technical stuff: the mathematical theory of patches, commutability, etc are nice properties but any versioning system has to fight a very uphill battle nowadays. Incumbents (mostly git) are very entrenched. I'd like to hear which reasonable expectations the authors of pijul have.

By the way, do you ever mistype it? How about a two or three letters official short name?

<comment><USER5> I'm one of the authors. We are actually quite optimistic about Pijul's possibilities. In particular, there are a few niches where people either:

(1) do not understand Git, can't learn it, still need a VCS. I have a few industrial applications in mind, not necessarily related to code.

(2) understand Git very well, and have spent too many hours debugging their failed merges, non-associativity issues, complex rebases. These users would know enough about "git rerere", for instance, to find the model of conflicts slightly absurd. For them, Git has become a source of cost in the project, and costs need to be kept under control. Again, I have at least one open source project in mind, and a handful of industrial contacts related to these use cases.

(3) many people in academia, even in computer science, collaborate on their LaTeX papers using various combinations of Dropbox and emails. This is because they are "principles people" and like to understand the principles behind what they're using. If a tool seems too complicated, it looks suspicious. But anyway, I have written papers with Git before, the "fun" of using Git often fades away as the deadline approaches.

Given the very young age of Pijul, I see this picture, and the interest many people have shown in the project, as quite promising. However, unlike what your post may suggest, I don't see Pijul as fighting against Git. Ultimately, when Pijul is ready, the two tools could become quite complementary:

\- use Git (with branches, but without merges) when you need a linear history and/or a Merkel tree of your content. Git is extremely efficient in disk usage and in speed of retrieving contents. Projects like "Software Heritage" are a good example of the perfect Git-but-not-Pijul user, storage of experimental data is another one ("I've done experiment X on day Y, the results were Z").

\- use Pijul when you want to collaborate efficiently on text documents, and manipulate your repository in an extremely flexible way, handle conflicts sanely, while minimising your planning and maintenance costs. Pijul will probably never be as efficient as Git in terms of disk space, but could become quite competitive in terms of merge speed. Agile teams, academic papers, are good examples.

<comment><USER16> Regarding your niche (2): what open source project do you have in mind?

<comment><USER5> One of the largest open source repositories ever:

[https://github.com/NixOS/nixpkgs](https://github.com/NixOS/nixpkgs)

</comment></comment></comment></comment><comment><USER17> For those who wonder what the heck Pijul is about, I'd like to emphasize these two articles linked at the bottom of the page:

[https://jneem.github.io/merging/](https://jneem.github.io/merging/) [https://jneem.github.io/pijul/](https://jneem.github.io/pijul/)

<comment><USER18> I read that merging blog post a while back but didn't completely grok it, I've yet to read the paper though. Do you know of any other write-ups on patch commutation?

<comment><USER17> Unfortunately, no. It's pretty much my only exposure to the idea.

<comment><USER18> A shame, thanks for the reply though. I'll set aside some time this weekend and read through it again.

</comment></comment></comment></comment><comment><USER19> Since pijul's key advertised strength is the use of patches for resolving merges, couldn't this just be a new merge strategy option for `git merge -s <strategy>`? In this case, the algorithm would just produce temporary patches out of git snapshots before running its own algo. Even if it comes out being slower than natively storing patches it would be worth the cost if it made complicated merges easier.

<comment><USER20> [https://pijul.com/faq/#why-not-a-git-merge-algorithm- instead...](https://pijul.com/faq/#why-not-a-git-merge-algorithm-instead-of-a- whole-vcs)

</comment></comment><comment><USER21> This just needs to ditch all of the command line stuff and explain the patch concept up-front. This was the most useful line:

> if we unrecord a patch with dependencies all its dependencies are unrecorded > as well.

Up until that point I had been thinking "but what happens with patches that depend on each other", and I don't think they really explain that ever on the Pijul website.

But it doesn't go far enough - how is the dependency automatically tracked for example?

<comment><USER22> Automatic dependency tracking is deceptively simple: If you think of a patch as something as simple as "Modify line 10 of file A from `dog\n` to `cat\n`", the dependency is obvious: whichever previous patch left `dog\n` in line 10 of file A.

In most cases that's good enough to get stuff done.

Of course, it's not automatic _semantic_ dependency tracking. It can't always entirely tell that Patch B depends on a "feature"/"flag"/"magic bean" in Patch A or it won't CI build, without additional information (such as a CI build process in a bisect, or a manual dependency flag from the author of Patch B or a downstream consumer).

</comment></comment><comment><USER23> I read the article. Then I read the home page. It still don't know why I should give it a try. The practical added value, espacially compared to the cost of switching, is not clear to me. "faster, easier, mathematically proved" is a bit fuzzy as a sale pitch.

</comment><comment><USER24> I'm very interested in Pijul! Patch-based version control always seemed like a much more intuitive paradigm to me. That said:

From reading these comments, I would say that perhaps the number one priority for the project is an education/PR push. The best way to draw in more users (and thus more developers!) would be to have your very own Steve Klabnik. Someone to produce not just reference documentation or a manual, but a good, long(!) and detailed introduction with the tone of a blog post. The "why Pijul" section of the manual is a very good start, and the blog posts I've seen (particularly Joe Neeman's) are very fantastic, but it needs to all be tied together in a single section on the pijul.com site and expanded upon.

Those docs should include a good description of what Pijul solves that git doesn't. That is to say, basically anything along the lines of "git has a hard time with _______. Will pijul be a silver bullet for that?". (Examples for _______: monorepos, rewriting history, completely purging some file or commit from history). It's unfortunate, but a lot of developers seem to look for what's "best". You see this with new programmers a lot. Any programming forum will have fresh faces asking "I want to learn how to program please tell me what's the best programming language". I've found the JavaScript community in particular is quite keen to chase the new shiny that everyone likes. It's part of why Rust obtained huge momentum so quickly. If there's a really good description of where Pijul beats the competition, it helps with these sorts of people.

And finally, those docs (even the bits about Pijul vs. git) need to be written with the assumption that the reader has little or no understanding of version control or git. The docs may have to link to some 'git in 30 minutes' blog post elsewhere on the internet, if necessary. Writing in that style will not only draw in the new users who will help show where Pijul and it's documentation are confusing, but it will ensure that even those with lots of experience with git but little understanding of it will be able to appreciate Pijul's design.

This is by no means meant to be a put-down on the project or the way it's been handled so far. There's a lot of negativity in the comments here, but I'm certainly not one to be negative about the project. :)

<comment><USER11> I would have two pieces of advice:

(1) Starting by explaining that Pijul works with patches probably isn't the best place to start. It might be true, but most people are going to think "but if I do 'git diff' I can get a patch, so it's not really any different." I would start with explaining the consequences of this e.g. better merging, and so on.

(2) Basically take all the questions asked on this discussion, and put them into an FAQ together with their answers. These are the same questions everyone else is going to be asking too. Even if these questions are misguided, that still doesn't change the fact that's what everyone's going to be asking.

<comment><USER25> Regarding (1): as someone new to pijul, I was thinking the same. Not just that, but I deal with patches in git all the time. I receive them, and I send them, via e-mail.

</comment></comment></comment><comment><USER26> > Pijul is the only version control system based on a complete mathematical > theory of patches. [1]

Can someone please provide a link to that theory?

[1] [https://nest.pijul.com/](https://nest.pijul.com/)

EDIT: This? [https://arxiv.org/abs/1311.3903](https://arxiv.org/abs/1311.3903)

<comment><USER27> I found this [0] to be a very readable presentation of the theory behind Pijul. Key point is that by representing state as an "DAG of lines" instead of as an "ordered list of lines" (i.e. a file), you are always able to do perfect merges. You then need a "flattening" step to get to a normal file, but that is handled same as any other patch.

All in all, I am a tempted to give this a try -- even though the mental model will require some mental rewiring.

[0]: [https://jneem.github.io/merging/](https://jneem.github.io/merging/)

<comment><USER5> > the mental model will require some mental rewiring

One must be pretty brave to admit that. Even though I'm a big user of Git (and a co-author of Pijul), I agree that you'll probably need to unlearn a number of things. But you won't need to relearn so much, the patch model is really more intuitive in many cases.

</comment></comment></comment><comment><USER28> Just a quick sanity check:

1\. machine going bad causes data to get corrupted. oh no!

2\. can still check the fiddly number with `git log`. whew!

3\. grab a clone from $untrustable_cloud and put it on another machine

4\. check the fiddly number of the clone with `git log` or whatever. It's the same as the other fiddly number. Hurrah!

5\. run `git fsck`. no problems.

6\. Keep working as if nothing had happened

Same/similar process for Pijul?

</comment><comment><USER29> Rule number 1 for project naming: choose a name which anyone can easily figure out how to pronounce.

</comment><comment><USER30> How is this any different from mercurial?

<comment><USER5> By having a mathematical theory of patches instead of a bunch of (user- friendly and often working) hacks. It's actually explained in the manual:

[https://pijul.org/manual/why_pijul.html](https://pijul.org/manual/why_pijul.html)

</comment></comment><comment><USER31> How is this better than git format-patch?

</comment><comment><USER32> Git and Subversion had a baby?

<comment><USER33> See [https://pijul.org/](https://pijul.org/) (and its inspiration, [http://darcs.net/](http://darcs.net/) ). It's actually something quite different from both.

</comment></comment><comment><USER34> This is basically how CVS worked, as inherited iirc from RCS. Presumably the authors know this, so they must be doing something different, though I can't tell what from the description or pijul's FAQ.

Perhaps they figured RCS, SCCS et al are so old that mentioning them would add confusion for most readers. Might be reasonable, but for me I am unclear as to what's up with Pijul.

(It's sweet that their host is named 'nest' given the name of the project)

<comment><USER5> I'm one of the authors, and we've done a lot of bibliography before engaging in such a big project. I'll talk only about the core principles behind version control, not about how things are actually implemented, or which options are the defaults in which tool.

Pijul is _absolutely not_ how RCS or CVS worked. Instead, RCS and CVS worked more or less like SVN (remember the "CVS done right"?), and SVN itself is not too different from "Git without branches", or "Centralised Git", in the sense that these tools are snapshot-based (even though the actual implementations may store patches sometimes). This means that they see history as sequential, and use algorithms to merge when necessary. One could actually very well simulate a large part of Git branches and merges using multiple SVN servers, even though that would obviously be quite cumbersome to implement and use in any concrete situation.

The only version control system one can clearly relate Pijul to is Darcs, using the idea that patch commutation is the main thing people care about. Unfortunately, Darcs has important complexity problems when dealing with conflicts, and Pijul solves these problems.

That said, short-lived branches ("feature branches") in Git mostly try to simulate commutation, i.e. independent development mergeable later, hopefully in any order (since they were written independently).

<comment><USER35> Kudos on your work. I'm looking forward to trying pijul - I used darcs in the past and I miss some of its capabilities in the current git monoculture. Please ignore the negativity if you can - it's not like anyone was taking git away from people by suggesting that they might try a new thing.

</comment></comment></comment><comment><USER36> People who have issue with Git are just doing Git wrong. They are the same that build a feature on one single big commit impacting lots of files. They forget to merge their hotfix back in dev branch, etc.

And Git punish those peoples, but your tool don't, how can i trust the code base ?

<comment><USER37> Git doesn't scale.

</comment></comment><comment><USER38> This is unreasonable. First of all, often you don't need patches, so it's premature optimization. Second, git decided specifically for the actual-state version to have this key-object store, which means you throw away not just the disadvantages but the advantages as well. Last but not least, git ALSO STORES DIFFS when it packs stuff up, which is what happens if big amounts objects need to be transferred or big amounts of old data needs to be stored.

That doesn't mean pijul is a bad tool. I didn't check it out. And I really think for everyday coders who don't want to become git-gurus it would be nice to have a simpler git-like VCS, for instance.

But the marketing must be updated according to the facts. Try to find features that people really care about, e.g. ease of use, e.g. integration with build tooling and docker, e.g. better federation through more automation which makes centralized servers like github go away.

<comment><USER39> The primary novelty of Pijul is its sound patch theory, not any kind of technical achievement like smaller repository size. I do think it's premature calling it unreasonable without understanding this aspect.

<comment><USER38> Why not summarize it a little if you feel that info got lost.

Technically if you need a patch you can generate it on the fly by comparing both objects (you can even do that in a bash script with `diff`, if you are willing to type in the logic to look up commit->tree->file->object-name first). So there shouldn't be anything lost. The only parameters I can see with storing diffs vs immutable objects is disk space vs processing time, which is also what git proofs by not storing old immutables and instead store diffs for old stuff (reducing space by increasing processing time).

<comment><USER39> Sorry, I was in a hurry and I think I mixed up articles since I think another one recently appeared on HN which pointed to a page with a much better explanation.

The main idea behind Pijul (as I understand it) is that it makes merging divergent branches correct and predictable by making patch application an associative operation.[1] What this means is that that, given patches A, B and C, it should be irrelevant whether you are:

1\. starting with A, applying B on top, followed by applying C 2\. starting with A, applying the result of C applied on top of B all at once

In other words,

        (AB)C = A(BC)

This isn't always what happens in git because it doesn't work with patches on an abstract level. Instead, it always works with _states_ of the branch heads (and sometimes the state of their branching point, i.e. BASE, in case of a 3-way merge).

As to why this matters, [2] and [3] has practical test cases where the difference of these two approaches is observable. [3] is an example of plausible C code where the non-patch approach may produce an incorrect result. It also demonstrates the way the patch algebraic approach is able to take individual changes into account and apply edits from the second branch in the correct place in the first branch, even though the affected code has moved in the first branch in the meantime.

The focus on patches has other important implications, such as the fact that branches then simply become sets of patches and cherry-picking retains the identity of patches instead of creating new, unique commits.

The other important aspect of Pijul is use of efficient data structures that are naturally suited to the problem in order to avoid suboptimal algorithmic complexity. This is explained in more detail here[4].

[1]: [https://pijul.org/manual/why_pijul.html](https://pijul.org/manual/why_pijul.html)

[2]: [https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html](https://tahoe- lafs.org/%7Ezooko/badmerge/simple.html)

[3]: [https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good- seman...](https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good- semantics.html)

[4]: [https://pijul.org/model/](https://pijul.org/model/)

<comment><USER38> I disagree with some of that. But first thanks for explaining more in-depth what is behind pijul. The main subthread I started because I didn't understand what it provides. If it can combine easier UX with more efficient diffing, then I think it is a very valuable contribution, actually.

Now some more in-depth bla bla if interesting:

> (AB)C = A(BC)

great feature request, I agree.

> This isn't always what happens in git

correct.

> because it doesn't work with patches on an abstract level. Instead, it > always works with states

Incorrect though. States, patches, these are just trade-offs. You can represent either in the other completely. Like you can build a list using a tree structure if you just allow one branch. Or you can also build a tree on top of a list structure, if your traversal algorithm knows which item-index to pick for a certain subtree's children. All trade-offs.

That doesn't mean "Pijul does better diffs" would be wrong, though. It can still be the case. But it doesn't mean that git would need huge refactoring to also implement that better-diff-algorithm. In the end implementing this better algorithm in git might be trivial for a git core developer if you can explain to him how it works.

If you think about it a diff between two states has an unlimited way of being represented. And considering minimal steps to generate the diffs with adding lines to the diff and removing lines from the diff, the whole thing is an abstract tree. Basically to achieve associative patches one needs to make sure to always traverse this tree in the same order. Git traverses greedily though, using the very first diff that is good enough as a final result. Probably the idea behind this was also smart. Do it quickly for now, and optimize it if needed later.

<comment><USER39> > Incorrect though. States, patches, these are just trade-offs.

I still maintain it is correct to say that git _at present_ does not work with patches on an _abstract level_. I do not mean to imply by this that patches cannot be recovered from states (they obviously can) nor that it would take a great refactoring of git in order to implement it in git.

On the contrary, now that Pijul has done the hard part of thinking about it and developing it into a theory, it would probably be a very useful addition to git, as you have noticed, if it can get mind share among git developers.

> Probably the idea behind this was also smart. Do it quickly for now, and > optimize it if needed later.

The issue is of course whether the property of associativity is useful or not in a correctness sort of sense. IMO, the answer is yes, and I would gladly take a small performance hit in order to have this result.

Also, I've seen one of Pijul's authors claim that it could be made competitive with git with regards to merging performance (in terms of time). It is already quite quick. We'll see.

Another point made by one of the Pijul authors elsewhere in the thread is that Pijul uses novel data structures which enable it to also have _commutativity_ of patches. I'm less clear on how this works, but it essentially means that branches in Pijul become _sets_ of changes, not _sequences_ of changes. In other words,

ABC = ACB = CAB = <any other permutation>

This is what I hinted at when I said commits retain their identity across rebases and cherry-picking. At that point, history stops being important and you only deal with _changes_ as first-class entities. I feel this is enough to justify the claim that Pijul is fundamentally different from git by being patch-centric. I'm also not sure that this could be retrofitted to git as easily.</comment></comment></comment></comment></comment></comment>


Winner of the Stanford E-Week Challenge - <AUTHOR> http://blog.guykawasaki.com/2008/03/winner-of-the-s.html

<comment><USER2> I'd say that the breast cancer foundation was creating most of the value... 2nd, I don't see how you can call this innovative since there are a million things you can buy for which the proceeds go to charity.

But if you want to give it to them just for having a good heart then I guess that's alright.</comment>


Lockbox – A stand-alone password manager that works with Firefox for desktop - <AUTHOR> https://mozilla-lockbox.github.io/ <comment><USER2> I've recently moved from Lastpass to using Pass[0] & BrowserPass[1], just as convenient and allows me to manage the storing of passwords myself. All files are PGP encrypted. Storing my passwords in my self hosted GIT allows them to be checked out on to my tablet and phone for convenience as well.

[0] [https://www.passwordstore.org/](https://www.passwordstore.org/)

[1] [https://github.com/dannyvankooten/browserpass](https://github.com/dannyvankooten/browserpass)

<comment><USER3> Did you move away from Lastpass for any reasons other than self- storage/management of passwords?

Anecdotally it seems like a lot of people are losing trust in Lastpass. Just curious if this describes you as well.

<comment><USER4> not gp, but I did the same thing a few years back (well, lastpass->keepass->pass/git) primarily because I was sick of using a proprietary walled garden.

The main benefit of pass, for me, is that it's literally just gpg-encrypted text files. I can access my passwords even if I do not have pass installed, as long as I have my gpg private key. Using git to sync passwords makes it even better!

The android Password Store app (on f-droid) is a great graphical interface to my pass files, including handling git syncs.

<comment><USER5> Why did you move from keepass?

<comment><USER4> Two reasons:

1) I didn't like that its approach seemed overly complicated (e.g. its database format, client apps, etc)

2) I was having a really hard time synchronizing passwords, especially if there was a sync conflict. When they happened, the entire database was a 'conflict'. There were also issues I had with the actual sync mechanism, which at the time I had the database on a seafile instance and had to enable various 'hacks' in keepass to get it to play nicely (e.g. file locking, etc).

</comment></comment></comment></comment></comment><comment><USER6> This site doesn't answer the question 'why'.

Keepass usage seems pretty widespread. Okay Keepass doesn't integrate too well into browsers. But then why not just fix Keepass?

There have been way too many products pushed out failed utterly and abandoned by mozilla in the last few years. Why should I care about this one, if it doesn't even tell me what it wants to do better than other products.

The text on the website reads like this is simply a POC for a new built-in password manager in firefox, is that correct? But then why standalone?

<comment><USER7> 1\. Browsers are expected to have password management of some sort. Firefox's existing one is rather inadequate from a UX and security standpoint, as recently discussed.

2\. Browsers need to be trusted and secure. If you use Firefox, you are trusting Mozilla et. al. to have the policies, procedures, motivations, and expertise to create secure software that protects your privacy. If you can trust them to make your browser, you can trust them to make your password manager.

I do hope that Mozilla answers these questions directly when/before this moves out of beta.

<comment><USER8> > Browsers are expected to have password management of some sort. Firefox's > existing one is rather inadequate from a UX and security standpoint, as > recently discussed.

I'd like to see this discussion.

For me, I find Firefox's password manager the _only_ one I can bother using, because it offers a good and seamless UX, right where I need it.

If they "fix" that by making it terrible like Lastpass, I honestly don't know what I'll do.

<comment><USER9> > I'd like to see this discussion.

Concerning the "security standpoint", probably this news [0] is meant. Hashing the password with SHA-1 using 1 iteration may be referred to as "inadequate".

[0] [https://www.bleepingcomputer.com/news/security/firefox- maste...](https://www.bleepingcomputer.com/news/security/firefox-master- password-system-has-been-poorly-secured-for-the-past-9-years/)

<comment><USER10> Maybe if the hash were actually being stored, as in a website's accounts database, but SHA-1 is being used here to normalize a variable-length user- supplied password into a fixed-length string which can be used as the key input to an encryption function.

The article approaches this from an angle of an attacker with access to this hash bruteforcing it to obtain the original plaintext password. But as the hash is the encryption key, if an attacker were able to recover it from the encrypted password store blob, it would already be game over.

Applying a more costly hash algorithm would increase the cost of generating guessed encryption keys in a bruteforcing scenario, strengthening weak passwords somewhat. But using a single SHA-1 iteration here doesn't _weaken_ the password security model. A strong password will remain strong.

</comment></comment></comment></comment></comment><comment><USER11> I use KeePassXC [1] with Syncthing [2] to synchronize my passwords between machines.

[1] : [https://keepassxc.org/](https://keepassxc.org/)

[2] : [https://syncthing.net/](https://syncthing.net/)

<comment><USER12> I use a similar combo (keepssX+keepass touch with Dropbox to sync), and frankly it's a pain. There is no support at all in KeepassX for Dropbox or other sync methods, and they're not interested in providing it either, stating that a few triggers to auto synchronise is a viable solution.

Until an open source project takes multi device seriously, they don't get mainstream adoption.

<comment><USER13> I don't understand what "Dropbox support" is. Dropbox will sync any file.

<comment><USER14> I'd guess merge support in case of conflict and web GUI access.

<comment><USER12> No, keepass's recommended approach is a total PITA to set up, and completely non-intuitive [0].

[0] [https://keepass.info/help/kb/trigger_examples.html#dbsync](https://keepass.info/help/kb/trigger_examples.html#dbsync)

</comment></comment></comment></comment></comment><comment><USER15> Very pleasant and refreshing to see some activity on the OSS front here. I believe Mozilla would have the resources to bring this to a success. Although naivety aside - I think it'll take years to only slightly catch up with the comfort and usability 1Password already provides. While it's not OSS it is still the benchmark to beat in terms of usability and integration.

Good luck Mozilla!

<comment><USER16> Pass[0] is pretty great. GPG encrypted and synced with Git. There is a great cross browser extension called browserpass[1]. I have mine tied to my yubikey, so it needs a physical device to decrypted my passwords.

[0] [https://www.passwordstore.org/](https://www.passwordstore.org/)

[1] [https://github.com/dannyvankooten/browserpass#readme](https://github.com/dannyvankooten/browserpass#readme)

<comment><USER17> Doesn't saving each password to it's own individual file make it more breakable than saving everything together in one file? I presume they're all using the same secret at some level. There's no FAQ on their site.

</comment></comment></comment><comment><USER18> Installed it from the website, logged-in with my Firefox account and got redirected to allizom.org ("Mozilla" spelled backwards!) which has an untrusted certificate. Not a great first experience :(

<comment><USER19> What Firefox version are you running? This sounds like Firefox bug 1411646, which should have been fixed in Firefox 58:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1411646](https://bugzilla.mozilla.org/show_bug.cgi?id=1411646)

<comment><USER18> I'm on 59.0.1 (64-bit) for Ubuntu Artful (from the official repos). This is quite an odd bug, thanks for the link (and the link from the sibling comment). I'll keep an eye on the bug reports :)

</comment></comment></comment><comment><USER20> I saw this couple of days ago with Mozilla roadmap. But I have been wondering about few things.

1\. Why firefox only? 2\. Why encryption is limited to Firefox account.

Such lock-in with firefox doesn't make sense to me with Mozilla's vision. If it's due to this being an experiment still that would make sense but that should be made clear I think.

<comment><USER21> On the website it's explicitly stated to be a test without disturbing people using "Saved Logins". I suspect Lockbox will replace those in the future...

<comment><USER20> Hmm I read that. And I was wondering if that meant in future that open it up.

Now I'm wondering if this is essentially doing the coding outside core firefox project with the later plan to just integrate it fully into the browser. Almost like an experimental build kind of workflow. I guess that kinda make sense.

</comment></comment></comment><comment><USER22> Please take note of the "experimental" label on this open source repository, which is posted to HN every few weeks. Previously:

[https://news.ycombinator.com/item?id=15992762](https://news.ycombinator.com/item?id=15992762) [https://news.ycombinator.com/item?id=15997239](https://news.ycombinator.com/item?id=15997239) [https://news.ycombinator.com/item?id=15832879](https://news.ycombinator.com/item?id=15832879) [https://news.ycombinator.com/item?id=15596740](https://news.ycombinator.com/item?id=15596740)

</comment><comment><USER23> I didn't know what Mozilla Lockbox was, but I found this[0] which might help others.

[0] - [https://mozilla-lockbox.github.io/lockbox-extension/](https://mozilla- lockbox.github.io/lockbox-extension/)

</comment><comment><USER24> This looks interesting to finally replace the outdated Firefox password manager. It is especially important as it was recently shown that the protection by the "master password" does not meet modern security standards.

But what exactly is "stand-alone" supposed to mean in this context? At the moment it is distributed as a Firefox extension that replaces the Firefox password manager. This seems like the opposite of "stand-alone" to me, as you cannot use it without Firefox.

</comment><comment><USER25> > The Lockbox extension is a simple, stand-alone password manager that works > with Firefox for desktop

So it's stand-alone, but I need Firefox to use it?

<comment><USER26> I think they mean that it isn't baked in to Firefox. But I agree that that's a weird choice of wording.

</comment></comment><comment><USER27> Does this offer any password-sharing features? Can you share some passwords with other Mozilla/Firefox accounts?

<comment><USER19> Not yet. Lockbox's stored passwords will be integrated with Firefox Accounts sync before it is released.

</comment></comment><comment><USER28> Remember kids, don't trust anyone with your passwords, not even Mozilla.

That said, I enjoyed having a look at Mozilla's internal project management tool for this extension, [https://waffle.io/mozilla-lockbox/lockbox- extension](https://waffle.io/mozilla-lockbox/lockbox-extension)

I wish I could have the same kind of look into other company's projects.

<comment><USER29> "Don't trust anyone" is a bit strong, and probably counterproductive. Be careful whom you trust is better.

<comment><USER11> Doesn't client-side encryption effectively suppress the need to trust a third- party?

Edit : I wasn't referring to this specific case, where encryption is done with the code sent by a server.

<comment><USER30> You've still got to trust the software doing the encryption, and the other software on your machine that might be able to interact with the software doing the encryption (e.g., browser and other browser add-ons, particularly when using a browser-based client side encryption scheme).

<comment><USER31> In this case, the software is open source, so the software can be evaluated.

<comment><USER32> > In this case, the software is open source, so the software can be evaluated.

You enter your password on a page Mozilla serve[0]; they can change the source of that page at any time, and for a single user. They could for example, send your password in the clear back to their servers if they wished.

0: [https://www.mozilla.org/en- US/firefox/accounts/](https://www.mozilla.org/en-US/firefox/accounts/)

<comment><USER31> All of this seems to be very alpha, but it's described as a standalone password manager and as far as I skimmed the docs, the firefox account doesn't necessarily seem to be a requirement. It might be something the extension requires, though.

<comment><USER32> Ah, good point — I was thinking of the issues with Firefox Sync.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> So... Did this initiative appear because it came out that Firefox was using an ancient and astoundingly insecure practice for its prior password storage product?

Given Firefox was only 2 years ago so insecure it wasn't even a valid target for most browser pwn competitions, and just in this year we find out important code is still held over from those days, I'm not sure why anyone should trust Firefox.

<comment><USER19> This is not a brand new project. The first Lockbox alpha release was back in September 2017:

[https://github.com/mozilla-lockbox/lockbox- extension/release...](https://github.com/mozilla-lockbox/lockbox- extension/releases?after=0.1.1-alpha1)

</comment></comment><comment><USER34> Seems a bit late to get in the password-manager business, where you have plenty of incumbents (1Password, LastPass, Bitwarden, KeePass...) offering a plethora of features. The Mozilla audience likely overlaps most of the target demographic for such products already, and persuading people to switch will be very hard.

It could make sense if Mozilla were to develop a standard interface for all password managers, so I could swap implementations under the hood without having to deal with their (occasionally half-baked) extensions.

But I guess this is just a Big Rewrite of the venerable utility we've been using since the dawn of Moz.

<comment><USER31> I'm in the market for this. There are few usable password managers that reliably work on linux, windows, macos equally good. I'm currently moderately happy with pass, but the colleagues I need to share passwords with are not CLI-fans as I am. 1Password doesn't support linux except in the webbased versions and I don't want that. Every time I need to touch Keepass I'd like to burn it. Haven't tried Bitwarden yet.

I'd love an open-source password manager with a modern ui and local storage.

<comment><USER35> Try enpass. Easy to use, good sync, cross platform (including linux).

[https://www.enpass.io/](https://www.enpass.io/)

<comment><USER36> Enpass looks wonderful. Lastpass used to export .csv, but now is only exporting in .html. Enpass imports only the older Lastpass .csv format. I may have to manually enter 280 websites, and 100 lines of secure notes. :( .... I will if I have to.

<comment><USER36> This is my 3rd year of LastPass, with auto-renewal in July, $24/yr. after $12/yr. for the last (LastPass) 2 years.be worth it Twice as much for something that still works stellarly. Mmmm..., might still be worth it. In the meantime I'd like to tryout Enpass as an alternative. If it works as well as LP, I might as well save $15/yr. with Enpass being as I'll purchase an Android Enpass app for $9.99/yr.</comment></comment></comment></comment></comment>


How I Defeated Type II Diabetes (2004) - <AUTHOR> http://shurie.com/lee/writing_defeat_diabetes.asp <comment><USER2> I liked his scientific approach. He listened to his body and found that eating only when he is hungry lowered his blood sugar. That is he waited until his sugar levels dropped to normal then he ate. I think this is a great discovery. Also shows there is a link between feeling hungry and the blood sugar level.</comment>


Ask HN: Review my Startup  - <AUTHOR>

OMMAGEO is a video sharing website that uses Google Earth as its UI, in addition users can filter videos in GE by @user, #keyword, and video date.
Here is a link to my walk-through demo:  http://solitaireinfosys.com/demo/will_brown/
I call it a "walk-through demo" because it is not fully functional, but is representative of the UI/UE.
Would you be interested in testing this when completed? If not, what would interest you in a new video sharing website, if anything?  Could you see this being an important video discovery tool for any specific industry?  Do you think this is a joke? <comment><USER2> Hi. It is kind of confusing. When I come to the site I don't really know what to do. I think the logo is odd for a video sharing site. Also what has bothered me when I first saw it is the similarity between the Sign Up and Sign In buttons. They look identical and it's confusing. If you are using it as a landing page, the Sign Up should be more visible, otherwise it is confusing.

</comment><comment><USER3> Like the concept, but I too am a bit confused. I appreciate it's not properly working atm. Maybe focus on news or some other domain where geography particularly matters. I think it's a step away from Alpha yet, but interested to see where it goes.

PS Like the logo, hate the name. Keep iterating that!

<comment><AUTHOR> I appreciate the look and response. I agree it could be appealing for news videos. I will keep hacking away at it and hopefully be live 12/21/12 (just in case).

Your comment on the name I will take to heart bc I don't even call it OMMAGEO. OMMA is Eye and Geo is Earth in ancient Greek so I call it iEarth, so I might have to rethink it.

</comment></comment><comment><USER4> I checked it out quickly, here are my thoughts:

1) Kinda confusing as to what you are supposed to do.

2) The you tube thumbnails are way to small to watch.

3) I'm sure there could be some interesting use cases for location specific video, but I have no idea what they are.

<comment><AUTHOR> Thanks I appreciate the thoughts.

1\. Sorry, I should have explained that the geotag function and search are not functional in this demo, this is more of a landing page.

2\. This issue goes to the demo itself, when the thumbnail is clicked the video would not play there rather the GE would zoom to the video geotag and the video would play inside the GE UI. If you are so inclined this function can be demoed here: <http://www.solitaireinfosys.com/demo/will_brown/test/>

Note there are 4 geotags uploaded in India, and you have to zoom in to GE just a little before the video geotags appear and here all 4 icons are default "x" but will be the @user profile pic.

3\. Thank you. My immediate thoughts are: a. news - click a news channel profile and see only their news videos across globe or a local as you like; b. events - zoom in on protest sites to see user generated content, or zoom in on stadiums to see videos of sports or concerts.</comment></comment>


Beyond Deep Learning – 3rd Generation Neural Nets - <AUTHOR> http://www.datasciencecentral.com/profiles/blogs/beyond-deep-learning-3rd-generation-neural-nets <comment><USER2> while the 3rd generation nn sounds interesting, the spike nn Spaun mentioned in the article doesn't seem to have any progress since 2012.</comment>


Show HN: Html-renderer-webpack-plugin - <AUTHOR> https://github.com/iiroj/html-renderer-webpack-plugin <comment><AUTHOR> I wanted to submit my webpack plugin for adding "SSR" to an otherwise basic static website built with Webpack.

I'm a UX/UI designer but for the past two years have started coding JS/React as a way to improve my design and systems thinking. My own static website has been the playground for most of that time.

I've been through Gatsby and Next.js and wanted to make my own static boilerplate, but the SSR part was missing. I looked at the existing webpack plugins for generating HTML files but thought they mostly deal with templates.

html-renderer-webpack-plugin tries to do things a bit differently by providing an SSR-like interface where each defined path (supplied in webpack config) calls a PromiseLike function where you can do whatever based on the current path and the webpack stats object. The function then should return a string of HTML that gets saved into the output directory. Basically this allows one to port their Express application's SSR functionality into a static renderer.

As linked in the readme, a working example site can be found at [https://github.com/iiroj/iiro.fi](https://github.com/iiroj/iiro.fi)</comment>


Hardware Implants - <AUTHOR> https://securinghardware.com/articles/hardware-implants/ <comment><USER2> A pencil point is a tapering edge, so I'm assuming the author is considering <1mm for "fully capable computer the size of a pencil point" being unreasonable.

Microcontrollers are not a huge amount larger than that any more:

-Cortex-M4f in 1.6x1.6x0.65mm (MAX32660)

-Attiny20UUR in 1.56x1.4mmx0.50mm

Bare dies may be a bit smaller than the above.

<comment><USER3> I would note that thinning and encapsulation of bare die allows typical thicknesses of <200um. Now, if you need an smt package and a (F)PCB then everything blows up to mm total thickness. Note also that typical minimum dicing width is 6-700um and your micros layout could be re-done to be a more toothpick 3x0.66x0.2 size. Still, gotta get power in and signals out, but conformal parylene will cover ACF or wirebonds.

<comment><USER4> You can put a lot of tsvs across the border of IC and grind up to them, hoping that the wire will bond to at least one of them. And if you do bonding by hand, you can bond right to the metal if the oxide below is thick enough.

</comment></comment></comment><comment><USER5> The discoverability of a hardware hack as reported makes the whole thing fail to ring true for me.

As Joe alludes to, why do something so discoverable when there are numerous other attack vectors that would preserve plausible deniability?

It appears close to a one-time trick, if you're China. Once the trust is gone, it's not coming back. Supply chains are already coming back home due to automation and consequently less reliance on cheap manual labour.

The case would have to be compelling - something that could not be achieved otherwise. That case is yet to be made.

<comment><USER6> When you ask "why would they?" you can intuit a seemingly good case either way that they would or wouldn't (maybe they would because they're incompetent.)

Instead of relying on intuition, a more to-the-point question is "did they do it?" We have to wait for a definitive answer to this from the authorities.

<comment><USER5> No, we'll have to wait for some definitive proof.

</comment></comment></comment><comment><USER7> Coincidentally, Joe Fitzpatrick was also one of the experts cited in the Bloomberg article. It would have been great to see this kind of technical perspective in the Bloomberg article! Joe clearly has value to add to the conversation and it is disappointing that Bloomberg chose to leverage his credentials in the hardware security community to add fluff to their article instead of any real insight. Same with using Joe Grand as well.

</comment><comment><USER8> BMC threats are a sufficient reason to avoid server class hardware for some people. They even contain public remotely exploitable vulns.

</comment><comment><USER9> I love follow-ups like this from experts like Joe. However, he seems quick to dismiss a couple things as improbable due to cost. I don't know, but I wouldn't be so sure considering we're talking a nation-state actor here.

</comment><comment><USER10> I've got titanium nails (controlled through magnet remote) in bone which helped me increase my height from 5'8 to 6'2 my dream height.

The method is called distraction osteogenesis where bone is cut obliquely and distanced 0.8mm a day.

I got both femur and tibia through the procedure in both legs to preserve the biomechanics which have to do with the femur to tibia ratio.

That said i don't feel anything. But this change has tremendously helped me gain confidence. So, my atheletism isn't affected in anyway.

I always had technical competence but was sidelined because of my lack of confidence due to my below average height.

I saw some really tall guys without any degree getting the role which i had experience/qualification for without any issue.

Today, I am a CEO of a small company and no longer insecure :)

<comment><USER11> Your comment bot is acting up

<comment><USER12> My thoughts exactly, it was a nice try though, maybe a next version could actually parse the article in order to find the most prominent keywords/topics instead of relying on just the title.

I'm pretty sure this comment would have gathered a number of comments / upvotes if it was in the right context.</comment></comment></comment>


Arguments for Eating Meat Debunked - <AUTHOR> https://www.theguardian.com/environment/2020/jun/19/why-you-should-go-animal-free-arguments-in-favour-of-meat-eating-debunked-plant-based <comment><USER2> poor logic like this should be reserved for Buzzfeed</comment>


New online judge service dedicated to teaching programmers. - <AUTHOR> http://spox.spoj.pl

<comment><AUTHOR> SPOX has been built upon the same engine as ideone.com and spoj.pl, but dedicated to teaching in the context of private lessons or regular courses at different levels, starting from beginners to advanced university students.</comment>


Intro to Low-Level Graphics on Linux - <AUTHOR> http://betteros.org/tut/graphics1.php <comment><USER2> Personally I find the heavy use of ioctls in modern Linux APIs bit distasteful. Sure, its pragmatic and easy, but it really feels abusing the UNIX mantra of "everything is a file" when the only operation you can do for that "file" is some specific ioctls. I first noticed this in the very nice KVM article that ran on LWN few years back, and now again here. I really wish there was some more structured way of talking to the kernel, but I can understand that introducing a ton of new syscalls probably is not practical.

<comment><USER3> > Personally I find the heavy use of ioctls in modern Linux APIs bit > distasteful.

That's how things work in Windows as well. That's how userland talks to kernel mode drivers.

Well, except everything is an object.

<comment> Const-me > That's how things work in Windows as well.

GPU drivers are different. Basically, Windows have Direct3D already in the kernel, exposing relatively large API surface for the userland half of the driver.

[https://docs.microsoft.com/en-us/windows- hardware/drivers/di...](https://docs.microsoft.com/en-us/windows- hardware/drivers/display/windows-vista-and-later-display-driver-model- operation-flow)

</comment></comment></comment><comment><USER4> Interesting write up, but it would be useful to explain how major graphics APIs fit into this (i.e. Vulkan / OpenGL) and how it all glues together (GPU drivers with KMS/DRM and higher level APIs).

Also note, that Mir is now basically gone, Canonical decided now to stop that rift and stick to Wayland.

<comment><USER5> Also, I'm curious about portable (i.e. across different Unixes) low-level graphics, if such a thing exists.

I assume that the interfaces discussed here are Linux specific, and the BSDs have something different.

Does POSIX have anything to say about graphics interfaces?

What is the lowest-level portable way to draw graphics? X11?

It's funny, because I always thought of X as being more of a windowing abstraction, rather than graphics in general. Perhaps I am making a distinction that does not really exist.

Obviously I am not a graphics guy :)

<comment><USER6> The BSDs and Solaris/Illumos have had DRM for years (where available), but it tends to lag the Linux version significantly because it's not trivial to port the code from Linux. I'm not sure where the compatibility breaks relative to the code given on the page, but most of them have some derivative of the original drm.h header that defines most of the structs and ioctls mentioned (e.g. [1] [2] [3])

[1] [https://github.com/freebsd/freebsd/blob/master/sys/dev/drm/d...](https://github.com/freebsd/freebsd/blob/master/sys/dev/drm/drm.h)

[2] [https://github.com/openbsd/src/blob/master/sys/dev/pci/drm/d...](https://github.com/openbsd/src/blob/master/sys/dev/pci/drm/drm.h)

[3] [https://github.com/illumos/illumos- gate/blob/master/usr/src/...](https://github.com/illumos/illumos- gate/blob/master/usr/src/uts/common/io/drm/drm.h)

<comment><USER5> Ah, thanks. Interesting.

</comment></comment></comment></comment><comment><USER7> Using the Linux kernel API is too high level :) Back in 1999 I wrote a simple 3D engine that hooked into a lower level API: the code was calling directly into the VESA BIOS Extensions of the graphics card. This worked on Windows 98 I think, but not NT4. [https://en.wikipedia.org/wiki/VESA_BIOS_Extensions](https://en.wikipedia.org/wiki/VESA_BIOS_Extensions)

<comment><USER8> You used BIOS calls ? Luxury , I used VGA registers directly to get vga mode X back in the days. [http://www.jagregory.com/abrash-black- book/](http://www.jagregory.com/abrash-black-book/) now that I call low level.

<comment><USER9> You had a VGA controller? That's nice. I had to design my own back in the days. [https://github.com/a3f/r3k.vhdl/tree/Demo-v1/vhdl/io/vga](https://github.com/a3f/r3k.vhdl/tree/Demo-v1/vhdl/io/vga)

<comment><USER8> You have an FPGA ? That's also nice, all I have is a bunch of resistors and a MCU :) [https://hackaday.com/2014/02/23/the-bitbox-console-gets- upgr...](https://hackaday.com/2014/02/23/the-bitbox-console-gets-upgraded/) (nice project btw !)

</comment></comment></comment></comment><comment><USER10> These articles always make me appreciate the work that must go into something like SDL or OpenGL and the like. It's easy to take these things for granted, but if this is the stuff that they have to make everything work, then I have to give some props and respect to the authors.

<comment><USER11> A nice way to give value to it, and at the same time a learning exercise, is to try do implement software rendering like we were doing in the MS-DOS days.

For something more modern, grabbing an ESP32 coupled with a LCD screen, for example.

<comment><USER12> I made my first serious attempt almost as soon as I joined my university, CompSci. First attempt took a long time, as I did not really know how matrices applied to computer graphics, so I did all operations again and again, when they were required.

My first rotating cube "exploded" due to numerical errors, as I was modifying the geometry instead of using matrix projections.

That made me appreciate the linear algebra classes much more.

</comment></comment></comment><comment><USER13> great write-up, fbdev is straightforward but the kernel is phasing it out in favor of DRM, I hope DRM will maintain a fbdev emulation at least. it's sad SDL2 did not have fddev support either as most people are fond of doing opengl/2d/3d-accleration these days.

<comment><USER14> As much as I would want to push people away from the fbdev API (doesn't support multimonitor, page flipping, cursor planes, etc.), it will be supported in an emulation layer for new DRM-based devices. Mostly for fbcon, but still supported.

[https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_fb_helper.c)

<comment><USER15> Wouldn't removing it break the "never break the user space" promise Linux has?

<comment><USER16> No. The "never break user space" thing (AFAIUI, at least) is about not changing existing behavior. Removal of features is a different thing altogether which usually only happens after _long_ deprecation periods or when there's nobody around to support the code.

</comment></comment></comment></comment><comment><USER17> The frontpage mentions Wirth's Law: "software is getting slower more rapidly than hardware becomes faster". [https://en.wikipedia.org/wiki/Wirth%27s_law](https://en.wikipedia.org/wiki/Wirth%27s_law)

</comment><comment><USER18> Tangential question from an embedded-but-not-Linux developer:

The structs use the types like ____u32 __or ____u16 __. I know the kernel defines its own types for internal usage[1], but why redefine types exposed to user-space? Why not use C99 <stdint.h> types?

Is it only historical?

And why are they double-underscore?

[1] because... reasons? I never really understood why

<comment><USER19> Generally speaking when you interface with a c library you should use the same types it uses. So while you can like get by with `stdint.h`'s `uint64_t` on _most_ platforms you hurt portability.

Example:

This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void\ _`, and `uint64_t` aren 't all the same size (`long long` is `uint64_t`, while void\_ and `long` are `uint32_t`, but in kernel land `void\\*` is `uint64_t`).

Just like C11 Atomics can fail on ARM and PPC under some scenarios so the kernel doesn't use these as well.

Its my understand the Kernel supports more platforms then the C standardization committee xD

\---

So the kernel likes to define its own primitives, and when you interface with it its is generally best to just use those definitions. Or if you want to use _standard_ types, you have to understand you are hurting portability.

<comment><USER18> Thanks for your explanation :)

One thing I still don't understand though:

> _This is because `stdint.h` isn 't 100% compatible with _every_ platform > Linux supports. This gets in hair brained definitions of pointers lengths on > some obscure platforms. For example SPARC64's `long`, `long long`, `void` , > and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while > void\ and `long` are `uint32_t`, but in kernel land `voidx` is `uint64_t`)._

In these cases, you just defined the variably-lengthed types (void* ) using the fixed-length types (uint64_t). This would just demonstrate that the fixed- length types are absolute, and IMO then good candidates to base absolute-sized types on. And yet that's still not good enough?

A bit of googling brings up the book Linux Device Drivers 3rd Ed (2005)[1], in which chap11 specifically addresses the topic of types. It argues against the usage of standard C types (int, long, etc) specifically because of their size variability. That's all well and good, but _it doesn 't make any mention of stdint.h_!

A hypothesis comes up: maybe stdtint.h is meant to be a user-space header exposed by the system/compiler, and the kernel, having to be entirely bootstrapped, can't even depend on that? So it just redefines the types for itself? With the side-effect of exposing those to userspace at the API?

[1] [https://lwn.net/Kernel/LDD3/](https://lwn.net/Kernel/LDD3/)

<comment><USER18> Ah, found the explanation:

 _The problem with that idea is that the kernel cannot count on those types being consistently defined for all configurations, and cannot create its own definitions for the standard types. So the kernel /user interface must continue to be defined using kernel-specific types (__u16 and such)._

From: [https://lwn.net/Articles/113349/](https://lwn.net/Articles/113349/)

And as close to Word Of God as I can get:

[http://yarchive.net/comp/linux/int_types.html](http://yarchive.net/comp/linux/int_types.html)

</comment></comment></comment></comment><comment><USER20> I notice there are no pictures

<comment><USER20> Just how low level _are_ these graphics?

</comment></comment><comment><USER21> Quiet a bit off topic, but this website is a joy to browse just for it's simplicity, high visibility, and speed. Just good ole basic HTML & PHP pages without a ton of overhead.

<comment><USER22> > high visibility

Really? I found it quite difficult to read due to the text color being too close to the background color.

<comment><USER23> It's similar to my preferred terminal settings. Dark background, light grey text, some brighter colors to highlight important things.

<comment><USER24> For me, light fonts on dark backgrounds are very difficult to read, I quickly get a lot of after images making reading the text very difficult. I was always fine with green and amber monochrome screens back then - perhaps my eyes just were much younger. I have not been able to find out what changed that for me, unfortunately.

</comment></comment></comment></comment><comment><USER25> One would expect some images in a graphics tutorial...</comment>


Show HN: Ahoy! Connect with people near you - <AUTHOR> https://ahoy.fm <comment><AUTHOR> Hello all, I released ahoy couple of months back in Hacker News. Now I am happy to announce a newer version of Ahoy. [https://ahoy.fm](https://ahoy.fm)

Changelog:

\- Updated design.

\- Ability to see how many users are near by.

\- Removed some features from previous version as it is not alligned with the idea of this app.

\- Hid the rarely used features to give more focus on the nearby feed. (You gotta find them to use them).

\- Smaller & cooler domain name :)</comment>


7 Life-Changing Perspectives to Overcome Your Family's Obsession with Stuff - <AUTHOR> https://www.becomingminimalist.com/overcome-family-clutter/ <comment><USER2> I'd add a few. One sample: the value of any entertainment you're saving, including books, including most non-fiction books, is relative. Aside from a very few favorites, it has to be significantly better than what you'll be able to stream, already have in the cloud, or can find online fairly easily or you shouldn't consider keeping it. Whether it's a good book or movie or CD doesn't matter: is it really better than what you're going to come across for free or can stream. That's the question that matters.

Consider the use someone else can make of it. Thrift stores are a good thing; hoarding something until it's old and out of date not so much.</comment>