Akin's Laws of Spacecraft Design - <AUTHOR> http://spacecraft.ssl.umd.edu/old_site/academics/akins_laws.html <comment><USER2> I love #6. _(Mar's Law) Everything is linear if plotted log-log with a fat magic marker._

People say lol a lot when they didn't really. But I really did at that one. Because I know exactly why it is true. What's going on is that you have a high order term that dominates the big-O. As long as that is anything of the form x^k it will be linear, and the lower order terms will show up as minor deviations, which the magic marker smoothes out.

Since big-O scaling terms of that form arise in a lot of different equations, it is very common that real data DOES show up as a (reasonably) straight line on a log-log graph. And the slope of that approximate line tends to be very useful to know.

But if you see data set after data set plotted on log-log with magic marker lines drawn, it is easy to ridicule the phenomena. :-)

</comment><comment><USER3> > In nature, the optimum is almost always in the middle somewhere. Distrust > assertions that the optimum is at an extreme point.

This one caught my eye as being only half right. As you increase something, you may get better performance up to a point but then see it level off and decrease. For instance, you could increase the fuel capacity by a factor of 10, but then you'd need a larger engine, more powerful thrusters to maneuver it, etc.

On the other hand, the lower bound of "don't do that at all" is _frequently_ optimal. A lot of these cases are things that you'd intuitively see as stupid ideas (ie "how many lead weights should we bolt on to the fins"), but in other cases they aren't. Like a fish that evolved away its eyes because they were no longer useful. (<https://en.wikipedia.org/wiki/Amblyopsidae>)

If you took the "law" too literally, you'd be distrustful of saying "These eyes aren't doing anything, let's have 0 of them." Don't be afraid to remove wasteful features.

<comment><USER4> I'm sure that I'm going to be caught out for mis-remembering this... but I recall something from Richard Feynman's auto-biography where he's describing a piece of advice from when he was working on a mechanical analog computer (for ack-ack aiming) you pick the gears from nearer the middle of the range if you possibly can.

I've worked on projects that were burned by incorporating too many bleeding edge components, when things are too new, you often don't know what you don't know.

I'm sure if I had this list to point to on my last project, I'd either have been shown the door sooner, or we might have had a better chance of success...

<comment><USER5> I remember that about the gears, too. IIRC, the big ones were too expensive and the small ones' teeth broke.

</comment></comment></comment><comment><USER6> > 3\. Design is an iterative process. The necessary number of iterations is > one more than the number you have currently done. This is true at any point > in time.

> 7\. At the start of any design effort, the person who most wants to be team > leader is least likely to be capable of it.

Some of these adages are universal.

<comment><USER7> So good leaders aren't allowed to want to lead?

<comment><USER8> I think that the qualifier "At the start" is important, here. I've known many good leaders who, at some point, got frustrated and took charge. I've also known a lot of jerks who wanted to be in charge of things as soon as they heard that there was going to be something to be in charge of.

</comment></comment></comment><comment><USER9>
      15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces.
      This is also the prime location for screwing it up.

So true. Parnas' paper on information hiding and decomposing into modules is of course also about choosing the interfaces [https://docs.google.com/viewer?url=http://www.cs.umd.edu/cla...](https://docs.google.com/viewer?url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf) (bonus: he describes the genesis of the paper, see the "quick view" of the top of this google search [https://www.google.com/search?q=filetype%3Apdf+parna+on+the+...](https://www.google.com/search?q=filetype%3Apdf+parna+on+the+criterion+for+decomposing+into+modules))

Unfortunately, once you've chosen interfaces that hide the details and things likely to change, it becomes harder to change the interfaces, in case you were wrong in your predictions of what will change in the future... Or, if you just didn't understand the best way to approach the system... (how could _that_ happen?)

It's hard to change because other modules depend on this interface. Unit tests operate on the interfaces between modules, so they need to change too... and you won't have the safety net they provide. Documentation must change. etc.

Therefore, in practice, interfaces are _not_ changed.

<comment><USER10> I thought it was an interesting point and it reminded me of something. I've worked on an iOS project with a really ugly web API. I could improve the project internally quite a bit by making a native iOS API that I would talk to, which would hide lots (but not all) of the uglyness of the web API.

So I guess if one deals with ugly interfaces it may be wise to wrap the ugly interface in a cleaner one. As an added benefit, the project is decoupled more from the ugly interface, perhaps permitting to replace it with something better in the future.

<comment><USER11> "All problems in computer science can be solved by another level of indirection." — David Wheeler [1]

[1] [https://en.wikipedia.org/wiki/David_Wheeler_(computer_scient...](https://en.wikipedia.org/wiki/David_Wheeler_\(computer_scientist\))

</comment></comment></comment><comment><USER12> These are fantastic, and many apply to general engineering and design, including software systems. Thanks for sharing!

By the way, I believe a more up to date URL is: <http://spacecraft.ssl.umd.edu/akins_laws.html>

<comment><USER13> Somehow the added ones don't seem as insightful as the rest.

</comment></comment><comment><USER14> #41: The bridge must have kicky furniture that is stuffed with fragile explosives and easily ruptured fog vents

</comment><comment><USER15> Very early in my career, early enough that I could fully appreciate its relevance for another few decades, I stumbled across a copy of Arthur Boch's _Murphey's Law and other reasons things go wrong_. The fundamental truth of the astute, or more often, pained, observations of engineers continues to impress me.

The 26th anniversary edition was released (or escaped) in 2003.

[http://www.amazon.com/Murphys-Law-26th-Anniversary- Edition/d...](http://www.amazon.com/Murphys-Law-26th-Anniversary- Edition/dp/0399529306)

</comment><comment><USER16> Kelly Johnson's 14 Rules of Management are also great.

[http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson....](http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.27s_14_Rules_of_Management)

Note the unwritten 15th rule: _"Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy."_

</comment><comment><USER17> > 11\. Sometimes, the fastest way to get to the end is to throw everything out > and start over.

...for all the people saying that a software rewrite is never worth it :)

<comment><USER18> I think there are stages during preliminary development when this can be true, but once you ship to customers you cross a threshold it's hard to pull back from. Twice now I've seen whole companies brought to their knees and sold off for scrap because rewrites of successful products failed.

</comment></comment><comment><USER19> (Tupolev-Bartini law) An ugly plane won't fly.

</comment><comment><USER20> It's depressing how much of these are perfectly applicable to software development for large companies. At least most of them are valid in my current job.

</comment><comment><USER21> Number 20 describes much of the world.</comment>


Outsource Google Analytics Data Analysis [Join My Beta] - <AUTHOR> Data Analysis is extremely valuable for small businesses, yet it's incredibly time consuming and complicated.
I'm working on a tool to analyse automatically all your online business data (Google Analytics, MixPanel, Heap, Social Media etc) and let you know precisely what you need to know, not only copy pasting the metrics but really explaining you what they mean and what you can do to improve them.
My "lean" solution to this problem, which will verify my hypothesis (people will pay for data analysis) is a service where you can outsource this task.
Marketing analysts will clean your data from spam, and let you know with a report every Monday morning how things are going. For the beta we have only Google Anlytics.
Sounds interesting? Join our beta, currently 100% free and you get 2 weeks of data analysis 100% free. Http://Simplify.us
I look forward for your comments and suggestions <comment><AUTHOR> Signup here: [http://simplify.us](http://simplify.us)</comment>


Ask HN: Getting into the ML Field? - <AUTHOR> Recently I took a Coursera course by Andrew Ng on Machine Learning, and I have to say, I absolutely love this subject. Somehow it just clicks in my brain. I vectorized back propagation early on, even though in the course Andrew tells you not to try at first, and the speed improvement was a marvel to behold.<p>So, to sum up, I really love the subject and want to learn a lot more! But I also need to eat ;) and I learn way better while doing. My background is in law and finance, though I do have coding skills in Swift, JS, PHP and Python, but nothing significant. Any recommendations for getting into the ML field without official CS degree or something similar? I think I'll really love it, and would be good at it. Thanks! <comment><USER2> Algorithmic trading, if you are good at both the finance bit and the software bit. Caveat Emptor.</comment>


ESA experimental spaceplane completes research flight - <AUTHOR> http://www.esa.int/Our_Activities/Launchers/IXV/ESA_experimental_spaceplane_completes_research_flight

<comment><USER2> 2 ton, 5 meter spaceplane? That's tiny, about the same size as a Cessna. It's even smaller than a Soyuz reentry capsule.

<comment><USER3> Pretty small. You might say: "It's experimental. Might as well make it small so you can put it on a cheap(er) rocket like the Vega." But they seem to want to make a full system (the PRIDE spaceplane) that also flies on the Vega. The Vega can theoretically lift 1 more ton than the IXV weighs, so there's not a lot of room left for a "full-size". Not quite sure what you do with a small reusable platform. Maybe space systems and sensor development, so they get to fly in the real environment but you can bring them back for analysis. But probably just fulfill the "D" in the name: "Demonstrator." Prove that you can do it so you can try to get money for a larger version.

<comment><USER4> I think the purpose of this program is to provide the ESA with independence from the Russian and American space programs, so with this in mind the IXV and its follow-on projects are going to be very interesting.

Did anyone else notice how _fast_ the Vega liftoff was? I think thats probably one of the fastest, smoothest takeoffs of any launch platform I've seen lately .. certainly impressive.

<comment><USER5> > independence from the Russian and American space programs

especially given that the capability for global high-precision strikes with highly-maneuvering hypersonic reentry vehicles is a must-have part of very near future arsenal.</comment></comment></comment></comment>


Working at Amazon - <AUTHOR> https://www.tbray.org/ongoing/When/201x/2017/10/26/Working-at-Amazon <comment><USER2> The biggest flaw in working for all those mega corps, is that despite their size, they still haven't fully embraced remote work. Yes there are island, but Amazon are still looking for that "2nd city" to locate in. Some people may dig going to an office, I don't. If you're lucky to be early in a given neighborhood, you can probably retire on renting out your house. If you're late, like applying to Amazon now would be, you're just a blue collar worker, with higher turnover - you earn more and spend on rent. Especially in places like Seattle if I was to relocate with the family, I'd be an indentured servant, with obligations to pay high rent/mortgage, I'd probably have nowhere to change jobs to, if Amazon didn't work out.

One can dwell on small things like which version control does a company use, but ultimately, they are failing to deliver on the "quality of life" thing.

<comment><USER3> > Especially in places like Seattle if I was to relocate with the family, I'd > be an indentured servant, with obligations to pay high rent/mortgage, I'd > probably have nowhere to change jobs to, if Amazon didn't work out.

That's quite the opposite. Wouldn't living in a big city mean more choices? Seattle for instance has high paying job options from Microsoft, Google, FB if you decide to leave Amazon.

However, yes having more acceptance of remote work would be great.

<comment><USER4> Aren't the Google and FB offices in Seattle relatively small, satellite offices?

<comment><USER3> Google Seattle-Kirkland is the third largest Google office. I wouldn't classify it as "satellite".

<comment><USER5> There is no such thing as "Google Seattle-Kirkland", no matter what the managers and recruiters may tell you. There is "Google Seattle", which is located in the Fremont neighborhood, a small and friendly office which I would definitely classify as a "satellite"; then there is "Google Kirkland", located on the other side of a large lake, over in the direction of Microsoft, which is certainly a big place. Still... Google is all about the mothership. Everything is centered culturally on Mountain View (called "MTV" internally).

Well... that's how it was when I worked there; things could have changed a lot in the last five years, perhaps. It sounds like the new Seattle office they're planning to build will be less of a satellite.

</comment></comment></comment></comment></comment><comment><USER6> Amazon has one thing going for it that I think is a huge deal for a standard BigCo job: if you don't like your initial team, you can switch ANY TIME. And if you're an engineer, you can probably join any team you want.

The reason this is such a big deal is that when applying to any company, you'll get placed on a team and it's really hard to get enough information on the culture, mission, management, etc. Once you're inside? Tons of information, and a lot of coworkers you can ask. This really reduces the downside risk of a new job.

I know this because I work at Amazon, and switched teams very early. I'm much happier on my second team, and probably would have quit on the first team.

<comment><USER7> What was wrong with the first team? How large are teams, generally? Are we talking like, six people, or sixty?

<comment><USER6> I didn't like the project I was assigned, didn't like the underlying design of the org's charter, didn't like the hours. I also got transferred between managers. I didn't really like it from the director down. It sounded way cooler from the pitch the hiring manager gave me. Team size is not a well- defined concept, TBH -- hierarchies can be structured in very different ways, and a team can be comprised of people with different managers. Also, if you love your director and adjacent teams, it would be unlikely you'd hate your own team.

Once I was inside, I found a few teams that sounded cool. At that point, I could easily meet people on those teams, read survey results on the managers, ask around about the new teams, visit the offices at 6-7 PM and see who was still around. This is somewhere between 10-100x the information I could get as an internal employee than as an external applicant. This led me to joining a team where I'm very happy. And if things went really badly -- I could have switched again! (Might look bad if you switch a ton though)

</comment></comment></comment><comment><USER8> I think AWS is probably the place to be Amazon. The whole idea of the cloud is that everything gets automated so good and clean engineering will be rewarded. I think working on the Amazon e-commerce is much less fun because it's much messier to deal with issues like customer support, taxes and other stuff.

</comment><comment><USER9> it's interesting how Amazon is now positioning themselves as a tier 1 employer.

They used to be a tier2.

AFAIK they also have a brutal pager culture where you're awoken in the middle of the night.

<comment><USER10> > pager culture where you're awoken in the middle of the night

For multinational corporations, this has never made sense to me. Why do we insist on relying groggy, "at the bottom of their performance curve" engineers to keep your system up, instead of someone in the middle of their work day?

IMO, if you're waking someone up in the middle of the night, something is horribly wrong, and it's not the issue you woke that person up for.

<comment><USER11> Having done Amazon on-call for five years, I can give some background on that.

First, the front-line pager duty is usually hit by an ops eng team first. Each of those teams has an India group and an North America group. If they can't resolve the issue, they page in the developers. Having good Ops Eng guys supporting you is a blessing.

There's also a very strong incentive for teams to write good software and test before deploying when you know damn well that if you're deploying something that doesn't work, you're the guy who will have to deal with it at 3am. Having strong integration and system tests suddenly becomes incredibly important.

Edit: and as dsfyu404ed said, the Ops Eng guys will be smart enough to narrow down where the problem is usually. If you're being paged, it's usually your team's fault.

</comment></comment></comment><comment><USER12> Thanks for writing this, and with all due respect:

This exact article could have been copy/pasted from any of the other big-tech companies. What makes Amazon different?

<comment><USER13> The author says as much:

> ...but at the end of the day it's just another high-tech company, > nothing surprising.

<comment><USER14> So, basically:

"If you like being shunt into small teams to work on small projects that take too long and go nowhere, being unable to effect larger changes that actually improve things upon the sprawling mass of wasted effort and reinvented wheels, no long term organization or planning or realistic goals, no semblance of cross-group communication or organization, total enslavement to a disjointed hierarchical mess of disparate initiatives that are ignorant of one another (to say nothing of even caring to help each other), and wasting half your time supporting legacy systems that nobody has the energy or balls to finally put in the dirt, welcome to working at a big tech company."

I might be a little cynical.

</comment></comment></comment><comment><USER15> > I could go on about diversity ... and so on, but at the end of the day > it's just another high-tech company, nothing surprising.

Dealbreaker. "On balance" in this industry isn't good enough, and if any company can take a leadership role in promoting diversity, it's one of the Big Four.

</comment><comment><USER16> The site is now offline, probably due to load.

Google cache link for the lazy: [https://webcache.googleusercontent.com/search?q=cache:70Vxjs...](https://webcache.googleusercontent.com/search?q=cache:70VxjsUrScIJ:https://www.tbray.org/ongoing/When/201x/2017/10/26/Working- at-Amazon+&cd=1&hl=en&ct=clnk&gl=uk)

<comment><USER7> Thanks for the mirror, but my God this is a tepid article.

TL;DR - Working at Amazon AWS is just fine and pretty much what you'd expect.

</comment></comment><comment><USER17> While informative, this post is extremely non-contentious, and i suspect on purpose. Much of what is said here can be said about most companies that are at scale. Probably by design b/c if his employer or manager found out about it, i am sure there would be backlash.

</comment><comment><USER18> I heard they will actually cut your base pay if stock goes up "too much". Is this true?

<comment><USER19> This is not true. However there is a target total compensation range for your [level X review ratings] and if the stock price growth results in your future total compensation projecting above your target compensation range you won't get refresh RSU grants.

<comment><USER18> What's the justification though?</comment></comment></comment>


Untangling the Web: a guide to internet research [pdf] - <AUTHOR> http://www.nsa.gov/public_info/_files/Untangling_the_Web.pdf

<comment><USER2> Screenshots of mostly-text web pages, compressed to JPEGs, pasted into a Word document, printed to hardcopy in two-level greyscale, annotated with a rubber stamp (or typewriter?), scanned again at low dpi, converted to PDF (39 MB), and drop-published into an unnavigable /_files/ folder, all towards its goal of teaching internet literacy to others.

<comment><USER3> Sounds like Web 0.1 to me [1]

[1] <http://thedailywtf.com/articles/web_0_0x2e_1.aspx>

</comment></comment><comment><USER4> Scribd is broken without javascript. Here is a better link:

<http://www.nsa.gov/public_info/_files/Untangling_the_Web.pdf>

</comment><comment><USER5> Wow, ancient web history. I suspect it was already outdated when it was written...

<comment><USER6> you nearly took a line out of the book. Third paragraph, page five,

"I cannot emphasize strongly enough that this book was already out of date by the time it was published"

</comment></comment><comment><USER7> This document is 4 months younger than IE 7.</comment>


Coronavirus: Iran's deputy health minister tests positive as outbreak worsens - <AUTHOR> https://www.bbc.com/news/world-middle-east-51628484 <comment><USER2> "Iraj Harirchi was sweating profusely at a news conference before testing positive for coronavirus disease"

It is a little worrying when an MP who is partly responsible for the health system attends press conferences when feeling sick.

Here in NZ we have posters up all over the place, especially government and educational buildings, saying if you are sick with the virus symptoms let a health professional know and stay away from other people.

We have no known cases but strong trading links with China.

</comment><comment><USER3> Stay safe everyone!</comment>


Tell HN: HoloLens 2 OMG - <AUTHOR> You need to experience this, it's 100x better then the first time I took real drugs<p>Will follow up with a video of I ever come down <comment><AUTHOR> Literary, I wish there was a way to give more slow clap for MS on this one, as a 20+ year Linux user, more</comment>


Scripting the Haiku GUI with hey - <AUTHOR> https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting_the_gui_with_hey/ <comment><USER2> I haven't tried BeOS/HaikuOS or the hey tool, but I've used the equivalent on macOS. The hey language seems a bit awkward to me, just like AppleScript. A few years back Apple added JavaScript support for OSA, which was a huge win for me. It took me a while to learn how to navigate the docs and use the APIs, but it's proven to be incredibly powerful.

Over time I've built up a small list of utilities for common UI interactions. Here's an example: Get the list of tabs from the frontmost Safari window [0]. Occasionally I'll be researching some topic with a bunch of tabs open, and I want to go work on something else. When that happens I just grab all the URLs in that window and save it in a text file which I re-open later when I want to continue researching the subject.

IMO, the biggest problem I've encountered with OSA scripts (and presumably it also applies to this hey tool) the lack of REPL and inspector. On macOS you can use Safari's dev tools to debug JS OSA scripts, but it's incredibly brittle. Trying to access certain object properties will just cause it to crash, or it might print the identifier of the thing which you're accessing which doesn't add much value.

[0] [https://gist.github.com/cesarandreu/8d6ccd70bcac81d1a45941ae...](https://gist.github.com/cesarandreu/8d6ccd70bcac81d1a45941ae996a6e32)

<comment><USER3> I understand not fixing something if it isn't broken, but is there a reason you don't just use a "Bookmark Open Pages" feature? I'm pretty sure it's standard in the big browsers, but definitely on chrome.

<comment><USER2> I just checked with Safari and it does indeed provide that functionality, and I wasn't aware it was an option.

Honestly, I just find it convenient to get a list of URLs, and dealing with regular text files. Sometimes interfaces are too limiting r slow, and manipulating the list in a text editor ends up being easier.

Another of my use-cases for this is to regroup tabs when I fork into random topics. e.g. Sometimes I end up opening a bunch of tabs that are tangentially related to the subject and I want to move em into a new window or stash em for later.

It's also convenient to grab a manually opened list of URLs in cases where I want to perform some one-off scraping task.

</comment></comment></comment><comment><USER4> I use AppleScript frequently, and one of the reasons I can't bring myself to move to Linux is because of the excellent API into every app.

Somehow "hey" just doesn't seem to offer the ecosystem that AppleScript does. Even though I really don't like the latest versions of macOS and iOS, I still prefer the old Apple ecosystem to the fragmented platforms of Windows and Linux (or Haiku).

<comment><AUTHOR> what exactly do you script with it if i may ask?

<comment><USER4> Mostly text processors. Bash scripting doesn't always handle Unicode nicely. For Pingtype ( [https://pingtype.github.io](https://pingtype.github.io) ) I need data in Chinese. I get that from websites. Sometimes I can download it with curl, other times I need to tell Safari to get the source for me. Language syntax like "every paragraph" and "set applescript's text item delimiters to" are much easier to handle than str.split() and IFS.

File reading and writing are easy. Getting and setting track data in iTunes is easy. Finding selected items in the Finder is easy. I've been using more "do shell script" recently as my knowledge of command-line tools increases.

It's slower to run than other languages, but when I just want a quick one-off script to generate some data, it's faster for me to code it in AppleScript instead of spending hours debugging it in another language.

All my processing for PlinyPedia ( [http://peterburk.github.com/pliny](http://peterburk.github.com/pliny) ) was in AppleScript - splitting the XML into separate files grouped into folders, naming those folders, moving the footnotes to the bottom and adding links to quickly move up and down, and finally generating a basic iUI interface.

I also wrote scripts to transpose chord progressions to Roman Numerals by looking up the values in a table, select cells diagonally in Excel, and turn my Facebook friends list into an iTunes database. (The iTunes database is URL tracks that trigger a PHP script running locally that opens Safari with the URL - it's basically a bookmarks manager with Smart Playlists. If you can recommend a better database, please do.)

<comment><USER5> Sounds like a good usage case for Perl rather than bash. The former has good Unicode support and you can use the standard lib + Mojolicious to fetch data from the web and serve other data to Safari. No need for bash + command line tools + PHP + web server.

<comment><USER4> I'm not trying to serve data to Safari (usually), I'm trying to read data from Safari. I often need to get the source of a webpage that's already loaded after a login screen, or with some user interaction.

For example, scrolling down to load all my Facebook messages into the left- hand bar. Or segmenting text into 5000-character blocks, copy-pasting into Google Translate, and getting the output.

With any command-line tools, it would be a hassle, if it's possible at all. With AppleScript, it's easy.

<comment><USER6> > For example, scrolling down to load all my Facebook messages into the left- > hand bar.

sounds like an X-Y problem. Why wouldn't you just use the facebook API ?

<comment><USER4> I don't think there's an API to export all my messages.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> the small titlebar seems neat, but the utility seems diminished (i have a smaller target area via which i can grab a window). does the compactness somehow play into other features of the windowing system, or is it just style?

<comment><USER8> You can stack windows together: [https://www.haiku- os.org/files/stack.png](https://www.haiku-os.org/files/stack.png)

</comment></comment><comment><USER9> Haiku could be the perfect netbook laptop OS IMHO. no nonsense but still modern.

<comment><USER10> Having used BeOS back in its halcyon days of the mid-to-late nineties and a as somebody that maintains an active Haiku installation (albeit under VMWare) I have to agree with you.

It is definitely lacking in the browser department (which seems so crucial to most people) but beyond that, it's a very dependable and responsive OS with absolutely modest hardware requirements.

(I also have a working BeBox 603e 133 MHz but I use it very rarely because I'm very concerned about the health of the IDE HD.)

<comment><USER9> all it needs for regular from out of backpack development use is a browser and docker.

</comment></comment></comment><comment><USER11> I played with BeOS when it was still alive, it was light, nice, and fun, and I miss these cute icons, but frankly, I simply don't see the point of reviving it now.

<comment><AUTHOR> There an insane amount of stuff to be learned from failures. From my understanding, one of the main reasons behind their demise was their business plan. Version for PCs with <256RAM were free, you paid for 256+MB. However BeOS ran so efficiently that no one ever needed 256+MB so few people bought it.

<comment><USER12> While it's been ~18 years, this doesn't at all sound correct to me. BeOS was a commercial product from its very beginning. There were free "developer release" versions, but it was sold as boxed software from R3 on. The last official release, BeOS R5, had a free version called "BeOS Personal Edition," which ran as an app inside Windows or Linux, but the full version of R5 was still commercial, at $69.95 (with an upgrade discount). I don't recall any licensing requirements pinned to the amount of RAM you had.

A large part of what did in BeOS was a combination of Microsoft's OEM licensing requirements and Be's steadfast belief that the only path to success was pre-installation on a major PC brand. IIRC, if you offered Windows pre- installations at all, you had to pay for every machine that Windows _could_ be installed on whether or not it was actually installed, and you couldn't offer machines capable of dual-booting. Be concentrated their efforts on BeIA, an "internet appliance" version of the OS, which was dead in the water -- according to a lawsuit Be filed against Microsoft, MS pressured their OEMs not to partner with Be on both BeOS and BeIA. (Microsoft settled the suit for around $24M, IIRC.)

Personally, I think BeOS might have been able to survive as a niche OS if Be had kept their focus solely on it, kept the price competitive with boxed Linux distributions (those were a thing back then), and _not_ been dedicated to the "go big or go home" mantra, but I don't have any inside info to prove (or disprove) that.

<comment><USER13> I was one of the people who worked at Be, right up to the very end, when the company went out of business, got absorbed into Palm, and I was laid off. I remember all this the same way you do.

... Except that I don't think there is anything they could have done that would have made them successful, at that point in time, other than possibly not playing hardball when Apple came calling. Microsoft's stranglehold on the industry was just too great.

<comment><USER10> I just wanted to let you know that to this very day I mourn the loss of Be Inc and BeOS. Whatever work you did there I'd like you to know (that for me at least) it was worth it because it left an enduring impression on those of us that had the privilege to use the system.

<comment><USER13> Unfortunately, I didn't do much to move BeOS further down the field. By the time I got there, the company had given up on BeOS as a standalone consumer product and was squarely focused on BeIA, specifically the Sony eVilla. (you can google it for the whole sad, sordid tale, if you dare.)

My contribution to the ecosystem, if in fact I ever made one, was to write what I thought of as the best USENET newsreader available on the platform.

[http://www.platinumball.net/pineapple/news/beos/](http://www.platinumball.net/pineapple/news/beos/)

I definitely would still be using BeOS today, as my day-to-day OS, if that were remotely possible, in this day and age.

<comment><USER10> I remember using that. I think I even registered.</comment></comment></comment></comment></comment></comment></comment>


Increasingly Dire Labor Shortages in Builder Trades - <AUTHOR> http://www.mortgagenewsdaily.com/09072018_home_construction.asp <comment><USER2> I've said the same thing several times in the last month on this website.</comment>


The Appification Of Everything Will Turn The Web Into An App-o-verse - <AUTHOR> http://www.forbes.com/sites/anthonykosner/2012/12/16/forecast-2013-the-appification-of-everything-will-turn-the-web-into-an-app-o-verse/ <comment><USER2> Doesn't this sound like a bunch of semantic nonsense? For years the web has been a shifting continuum of html/css/javascript and flash, supported by a standardized communication protocol, http.

Some of the processing is done on the client machine via "web browsers" and associated plugins and some is done on the server. Bottom line, at some point already passed years ago, advances in networking enabled computers to talk to each other, and various protocols were agreed upon to standardize this.

As computers didn't have much to say, scientists/engineers developed interfaces for people to use these protocols to communicate without having to understand them personally.

As it became clear that in addition to hackers, "regular" folks could benefit from the same communication channels, these interfaces (call them "apps" or "pages") continued to improve to what we see today.

It's clearly an evolutionary process rather than a revolutionary one.

</comment><comment><USER3> Is it doomsday again for the web already?

<http://www.wired.com/magazine/2010/08/ff_webrip/>

</comment><comment><USER4> I do agree with this article in that hybrid apps are a very viable option, but I feel a lot of what's said is fairly common knowledge.</comment>


Google announces Premium Support for cloud customers starting at $12.5k/month - <AUTHOR> https://siliconangle.com/2020/01/15/google-announces-premium-support-plan-cloud-customers/ <comment><USER2> We were seeing 15+ minute delays on every job submitted to AI Engine. That's 15 minutes to just get a traceback if your job failed immediately. They had to upgrade their internal k8s cluster and that took 6 months (??).

And their service would randomly fail entire jobs a few hours in that GCloud support engineers never diagnosed. We had people on-site too.

GCloud should be _giving away_ this advertised support plan _free_ for at least the next two years. Their stuff is way too unreliable to justify a support fee.

</comment><comment><USER3> The original announcement: [https://cloud.google.com/blog/products/management- tools/ente...](https://cloud.google.com/blog/products/management- tools/enterprise-support-upgrades-for-mission-critical-work)

</comment><comment><USER4> But you are already paying for your cloud resources! How can they justify charging you again to even support it?

</comment><comment><USER5> Will support be available if Google marks the account as malicious?

What's the point of paying when the biggest potential issue is Google itself disabling the account?

<comment><USER6> No, but you will get to hear Premium crickets after you make your request. :-)</comment></comment>


Interactive FEC Campaign Finance Data Explorer - <AUTHOR> http://blogs.splunk.com/2012/11/05/splunk4good-announces-public-data-project-highlighting-fec-campaign-finance-data/

<comment><USER2> nice way to explore campaign finance contributions by state, employer, job role, etc. Check it out.</comment>


X-rays could be used to cut down on problems bringing a new CPU to market - <AUTHOR> https://arstechnica.com/science/2017/03/bright-x-rays-reveal-3d-structure-of-processors-and-defects-lurking-within/ <comment><USER2> The article doesn't make this clear, but this is an excellent example of an area where "pure research" and practical technology overlap. Free electron lasers are essentially particle accelerators (of the same sort used in, e.g., the LHC) with special configurations of magnets stuck on the end. They are large, expensive to build, and expensive to operate for essentially all the same reasons that research accelerators are. So advances in physics which lead to advances in accelerator technology, which allow further advances in pure physics, also directly impact the practicality of using FEL X-ray sources for imaging microchips (among other things).

<comment><USER3> They aren't "essentially" particle accelerators, they are full-blown accelerators, linear accelerators, specifically.

</comment></comment><comment><USER4> Most of the problems with binging new digital ASICs to market have to do with the failure of -XRay-Lithography- EUV (now called Extreme UV) to provide fast enough exposures despite decades of development and billions in research investment. This is a hard problem, but quadruple patterning is also nasty and expensive at 7nm. Even if you can identify the error... if you can't make almost every one of a couple billion transistors correctly, you can't make a modern CPU.

I'd recommend reading a few recent articles on the topic:

The problem with lithography [http://spectrum.ieee.org/semiconductors/devices/leading- chip...](http://spectrum.ieee.org/semiconductors/devices/leading-chipmakers- eye-euv-lithography-to-save-moores-law)

A depressing conclusion [https://www.hpcwire.com/2016/07/28/transistors-wont- shrink-b...](https://www.hpcwire.com/2016/07/28/transistors-wont-shrink- beyond-2021-says-final-itrs-report/)

An optimistic expert [https://www.semiwiki.com/forum/content/6590-scott-jones- iss-...](https://www.semiwiki.com/forum/content/6590-scott-jones-iss-talk- moores-law-lives.html)

</comment><comment><USER5> This could be useful to reverse-engineers who may want to do security verification (are there a hidden backdoors in this chip outside its specifications?) or to simply clone a chip outright.

</comment><comment><USER6> I'm surprised lithography hasn't been replaced with something more nanoscale in origin like some kind of atomic deposition process where individual atoms are precisely bombarded onto the substrate to build up the features atom by atom.

It would take longer to manufacture each chip, but if the machines to do the deposition were relatively cheap and simple to construct, they're not that far off of electron beams, the result could be a massively parallel manufacturing process.

<comment><USER7> "Longer" if you're talking atom by atom is an understatement, you're going to almost never finish. Electron beams might be something relevant, but they're already being investigated.

E-beam lithography is a thing, and as with all next-gen litho techniques, it too has its fair share of problems. For example, shot noise is a major problem which means that every time you halve your node, you're going to halve your throughput. This is devastating for semiconductor manufacturing, TSMC is already working double shifts trying to match demand.

Also, the important thing to realize about semiconductors is that demonstrating something in the lab is a relatively easy ordeal, but making it mass manufacturable in a timely fashion with good yields is a herculean task. You can actually use X-ray litho for something more "nanoscale in origin" but it's really, REALLY difficult to make it in production.

<comment><USER8> > _You can actually use X-ray litho_

Wouldn't that result in a threshold shift? (X-rays are well beyond Si02 bandgap, so you'd get electron-hole pairs in the oxide. The electrons are fairly mobile, but the holes get trapped iirc.)

</comment></comment></comment><comment><USER9> > Essentially, it takes a very long time to obtain each pattern, and you need > a lot of patterns. By the time you've finished imaging, management has > brought you your golden watch.

What does this last part about the golden watch mean? Is it a reference to retirement?

<comment><USER10> Some companies gave out wristwatches commemorating significant tenures. There's even a Domino's Rolex.

</comment></comment><comment><USER11> Pardon my ignorance, but would it be possible to use X-rays to read the contents of memory? Say, in a TPM or Secure Enclave? I feel like if you had an accurate enough beam you could detect if a memory cell is "charged" or not.

<comment><USER12> I'm not sure about whether you can do that with x-rays, however you might find this paper interesting - 'Reverse engineering Flash EEPROM memories using Scanning Electron Microscopy' \- [http://www.cl.cam.ac.uk/~sps32/cardis2016_sem.pdf](http://www.cl.cam.ac.uk/~sps32/cardis2016_sem.pdf)

<comment><USER13> Thank you for that relevant article and interesting read. I don't know why you're being downvoted, but I did my part to restore the balance.

</comment></comment></comment><comment><USER14> It's an article about a paper published in Nature about X-Ray tomography to image nm-scale features in modern ICs.

And the only image presented in the whole article is a completely unrelated Chipworks die shot at about 10um per pixel.

</comment><comment><USER15> Wouldn't this method also erase any EEPROMs on the die?</comment>


Web Security Training Platform - <AUTHOR> http://ctf365.com

<comment><USER2> Ugh. I thought we left custom scroll bars and scroll behavior to die with Flash. I'm tired of choppy scrolling pages with a "pretty" colored scrollbar.

<comment><USER3> Do you have opinions on the actual platform?

<comment><USER2> Relax, go have a cig.

<comment><USER3> Hah. I just got off a 14 hour flight when I typed that comment. You have it spot on.

</comment></comment></comment></comment><comment><USER4> I'm getting an invalid cert error. :(

        The certificate is not trusted because no issuer chain was provided.
        The certificate is not valid for any server names.
        The certificate expired on 9/4/13, 6:55 AM. The current time is 3/5/14, 9:29 AM.

<comment><AUTHOR> Please send an email to email@example.com and the support guys will help you with. Thanks

</comment></comment><comment><USER5> [http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://ctf365.com)

<comment><AUTHOR> That is the old one in Alpha. The new site looks way better and detailed. :-)

<comment><USER6> Uh, if it is, that's exactly what I'm seeing on the actual production URL.

<comment><AUTHOR> your address was from webcahe. Try again [http://ctf365.com](http://ctf365.com)

</comment></comment></comment></comment><comment><USER7> Sounds a lot like [https://certifiedsecure.com](https://certifiedsecure.com)

<comment><AUTHOR> At this moment we haven't purchase any SSL certificates. We'll do when we'll go live. For some users that uses browsers that forces uses of SSL certificates they'll get that message.

Thanks

</comment></comment><comment><USER8> The country select box is disabled on the create team form. As a result I can't create a team.

<comment><AUTHOR> There is a small UX bug. It's because you didn't set up your country as a User. First go to your [http://ctf365.com/users/edit](http://ctf365.com/users/edit) and add your country there. Then the system automatically will register that country. That because as a Team Leader you'll fight for the country you came/declare from. It's Beta, we'll fix that too. :-)

<comment><USER8> Thanks - that was it.

</comment></comment></comment><comment><USER9> This looks interesting, but I'd really like some background on the project.

</comment><comment><AUTHOR> Now it's up and running back. Too many visitors we didn't expect. :-)

</comment><comment><USER10> It does not work for me :(

<comment><AUTHOR> there is some web issues due to the vast amount of visitors. It'll be back soon. Check it back later. Thanks</comment></comment>


The real reason only rich people can afford to live in Silicon Valley - <AUTHOR> http://www.vox.com/2014/7/13/5895181/the-real-reason-only-rich-people-can-afford-to-live-in-silicon-valley

<comment><USER2> > The Bay Area has plenty of room for more housing. [...] If housing > regulations were relaxed, developers would make room for millions of new > residents, creating thousands of construction jobs in the process. That > would alleviate the severe housing shortage currently plaguing the city.

Most people who bought houses in these cities while working wanted to sell up for as high a price as possible to retire in some cheap housing somewhere where they don't need to be close to a job. So they vote for city and county governments that restrict new housing permits. Reduce the supply of product to make the prices go up.

Those buying houses in smaller countries like Australia and New Zealand have had the complementary process available to them: boost the demand. They voted for the national governments that let in the most immigrants. That's why the housing industry didn't collapse in Australia/NZ around 2008 like it did in many US cities. They vote for the city governments that restrict new housing, and for the national governments that let in the most immigrants.

Reduce the supply and boost the demand to make the sale price on workers main asset go up quickly. They sell up, pay back the bank, and retire to some beach in rural Queensland.</comment>


Intel FPGAs Go Mainstream for Enterprise Workloads - <AUTHOR> https://insidehpc.com/2018/04/intel-fpgas-goes-mainstream-enterprise-workloads/ <comment><USER2> Financial companies have been using FPGAs and even custom ASICs for a while now for HFT.

If you are willing to buy old wireless towers in order to gain the speed of light speed increase in vacuum vs in fiber, custom silicon is chump change.

</comment><comment><USER3> Since this Intel, which is notrious in their PR, I must ask: this doesn't sound too important , it's just that 2 partners adding some more Intel products to their distribution.no big deal.

Or am I missing something?

<comment><AUTHOR> The article mentions FPGA accelerators in the Dell product catalog. Is that a new thing?

</comment></comment><comment><USER4> This seems to be part of Intel's intent behind their 2015 acquisition of FPGA manufacturer Altera. I am basing this off of the present state of Altera's website: [https://www.altera.com](https://www.altera.com)</comment>


Happiness depends on health and friends, not money, says new study - <AUTHOR> https://www.theguardian.com/society/2016/dec/12/happiness-depends-on-health-and-friends-not-money-says-new-study <comment><USER2> Well, after a certain point, definitely. But if you have to worry every single day if you gonna make it to another one with the bills and rent and groceries then money can definitely reduce stress.

</comment><comment><USER3> Having money isn't everything, not having it is.

</comment><comment><USER4> In other news; "Pope Catholic and Bears Shit in Woods, study finds"</comment>


Ask HN: Which Stocks to Buy? - <AUTHOR> Which stocks do you recommend to buy during the corona virus outbreak? <comment><USER2> Buy index funds. The risk associated with gambling on individual stocks is an order of magnitude higher during a period such as this. You don't need that extra risk to see gains.

</comment><comment><USER3> I've been focusing on blue chips that were already in the dog house, e.g. IBM, GE.</comment>


SW-delta: an incremental cache for the web - <AUTHOR> https://github.com/gmetais/sw-delta <comment><USER2> This might make be better as an RFC3229[1] (Delta encoding in HTTP) implementation-- putting the cache information in the querystring is strange when HTTP has a bunch of headers dedicated to it.

Cloudflare has a similar solution called Railgun[2] for updating dynamically generated pages. "reddit.com changes by about 2.15% over five minutes and 3.16% over an hour. The New York Times home page changes by about 0.6% over five minutes and 3% over an hour. BBC News changes by about 0.4% over five minutes and 2% over an hour."

[1]: [https://tools.ietf.org/html/rfc3229](https://tools.ietf.org/html/rfc3229) [2]: [https://blog.cloudflare.com/efficiently-compressing- dynamica...](https://blog.cloudflare.com/efficiently-compressing-dynamically- generated-53805/)

<comment><USER3> This was actually recently discussed on the github issues:

[https://github.com/gmetais/sw-delta/issues/1](https://github.com/gmetais/sw- delta/issues/1)

</comment></comment><comment><USER4> Out of curiosity, I went ahead and calculated deltas between jQuery 2.2.3 -> 2.2.4 minified versions.

It generated a 512 byte delta string, instead of downloading the new version of 83KB, 512 bytes seems like a pretty significant optimisation. Also, 2300 bytes for 2.2.0 -> 2.2.4.

I haven't seen a lot of great service worker uses so far but this seems plausible. Good job.

Delta if you wonder what it looks like: [https://gist.github.com/eknkc/fb27cfaee871a007c3cabfda5df03a...](https://gist.github.com/eknkc/fb27cfaee871a007c3cabfda5df03ab0)

<comment><USER5> Nice!

I wonder how the delta size compares to something like rsync or bsdiff?

<comment><USER6> 376 bytes for bsdiff(utf8, utf8), which is of course worse than brotli/gzip(utf8(text delta)) (267/305 respectively).

<comment><USER5> Interesting!

I looked into bsdiff, and apparently it internally uses bzip2 for compression of several components independently. As a quick hack, I modified it to output all those pieces uncompressed (producing a large file of mostly 0s), and then tried compressing the result with various compressors, both to test other compressors, and to compress the entire file as one unit rather than as separate components.

The result ("ubsdiff" is bsdiff without compression):

        85659  jquery-2.2.3.min.js
        85578  jquery-2.2.4.min.js
          376  jquery.bsdiff
        85994  jquery.ubsdiff
          264  jquery.ubsdiff.brotli
          252  jquery.ubsdiff.brotli9
          309  jquery.ubsdiff.bz2
          403  jquery.ubsdiff.gz
          360  jquery.ubsdiff.xz

So, 376 bytes for unmodified bsdiff, 309 bytes by compressing the whole uncompressed bsdiff file with bzip2, 264 bytes by compressing the whole uncompressed bsdiff file with brotli, and (strangely) 252 bytes with quality 9 brotli (the default is 11).

<comment><USER5> Trying the same thing with a larger delta (jquery-2.2.4.min.js to jquery-3.1.0.min.js) produced different compressor rankings, though:

         85578  jquery-2.2.4.min.js
         86351  jquery-3.1.0.min.js
          8663  jquery.bsdiff
        101359  jquery.ubsdiff
          8380  jquery.ubsdiff.brotli
          9209  jquery.ubsdiff.brotli9
          8853  jquery.ubsdiff.bz2
          9550  jquery.ubsdiff.gz
          8360  jquery.ubsdiff.xz

In this case, bzip2 of the whole file did noticeably worse than bsdiff's compression of three separate components. brotli of the whole file still won, though. Which made me wonder if brotli of the individual components would do better than brotli of the whole file. Turns out it does: 8006 bytes.

</comment></comment></comment></comment></comment><comment><USER7> Nice!

I've heard that Google's Inbox (and likely other websites) uses this technique, although the implementation AFAIU is not open source.

...actually, I think their's is different, in that it doesn't depend on service workers; AFAIU the approach is:

if you move from js-lib-v1.js to js-lib-v2.js, they'll go ahead and source js- lib-v1.js in the browser, and then also load js-lib-v1-to-v2.js, which is a server-side generated JS file that redeclares/redefines only the JS functions/modules/whatever that have changed from v1 to v2.

So, I believe their approach is much more intricate, because I believe it diffs the JS at a semantic level to generate the "patch the already-loaded JS by doing another JS load", vs. AFAICT your approach of just doing a textual diff.

Assuming my assumptions about both approaches are right, I definitely prefer yours in terms of simplicity; albeit the Google approach is (or was?) necessary to benefit most users.

<comment><USER8> I'm reminded of [https://github.com/google/module- server/blob/master/README.m...](https://github.com/google/module- server/blob/master/README.md) from a (linked) 2012 presentation. I believe I found it in 2013, there might be other more recent talks. If I recall, the unique feature of the proposed Google loader was that it would dynamically take into consideration a dependency graph of the next JS to load and serve up just enough to show whatever page you needed, and if the next page in the graph had different dependencies, it would load just the ones you didn't already have. Can't remember the details right now, it's been a few years. Made tremendous sense at the time, but the implementation might need to be improved a bit given HTTP/2 and more modern JS loaders, including a WhatWG spec.

</comment></comment><comment><USER9> I often see packages or solutions to problems related to browsers/servers on hackernews. Why don't people who make browsers or servers implement these things as a standard? IE. There seems to be so many people using jquery/react. Why not just implement some of their functionalities natively into the browser?

There seems to be a trend of making un-opinionated software that acts as more of a sandbox for down-stream developers. I think that's great because we are now seeing the great solutions coming out of that sandbox. But at what point do we start to have a general consensus and implement some of these great solutions natively to remove the resource overhead?

<comment><USER10> Do you really have to make them standard? There are not that many versions of most of these. Caching every common version of jQuery is pretty trival. The problem is that many people host it themselves or use one of many CDNs to serve it up and then expose users to the potential tracking that CDNs can do. Why don't the browsers just cache based on the integrity hash of the css and js links when it is there instead of the url? Then everybody can host his own copies for the cases where the user doesn't have it and cache hits will be much more common.

<comment><USER10> Concept covered in more depth here: [https://mntr.dk/2016/content-addressable- browser-caching/](https://mntr.dk/2016/content-addressable-browser-caching/)

</comment></comment></comment><comment><USER11> Chrome has had native support for SDCH[1] for years - I wonder why it hasn't been widely adopted.

[1] [https://en.m.wikipedia.org/wiki/SDCH](https://en.m.wikipedia.org/wiki/SDCH)

</comment><comment><USER12> Excellent use of service workers - are there any production sites around actively using service workers in production? Or are we yet to see the application of these mainstream?

<comment><USER13> I used Service Workers in production for a client to do offline mode and also to get truly instant page reload times for their SPA, which was important for kind of obscure reasons.

The Service Worker saved a complete HTML rendering of the current state of the React app, which was then served on reload, so that the correct view showed up even before any JavaScript was loaded.

Then in the next "requestIdleCallback", the React app was initialized with store data that was also cached.

It only works on Firefox and Chrome, so it's great for performance improvements or if you control the client's browser setup.

Other than that, try looking at your browser's debug pane for service workers and you'll see if any site has installed them. In my experience there are quite a few.

ProductHunt uses them to send notifications when you're off the site, which is a bit annoying, but maybe I said yes to it at some point...

<comment><USER14> That sounds like a great structure for instant page reloads. Any writeups on that?

<comment><USER13> I didn't, but I might soon... I'll email you if I do.

</comment></comment></comment></comment><comment><USER3> How does this interact with the browser's cache? For each potentially- cacheable request, the browser goes to its cache and looks up the entry by method and URI. When no hit is found, it forwards the request to the server, then depending on properties of the response, it may cache that response. At what point in the flow does the sw-delta-client code intercept the request? (Before the browser cache, or after the browser cache but before the web request?)

The sw-delta-client rewrites the URL, and the altered request is sent to the server. The server responds -- let's assume with a cacheable respone -- and the browser's cache gets updated.

Next time, we request the same URI but it's already cached and not stale, so it can be served right away from cache without having to go to the server. Does sw-delta-client intercept such a get-from-cache request? What if the cached entry is stale and needs to be revalidated by making a conditional GET to the server. Does it intercept revalidation requests?

Depending on some of these answers, the addition of query strings to the browser-perceived URI may influence whether browser caching is performed (properly, or at all). See: [1] [http://stackoverflow.com/questions/24354119/](http://stackoverflow.com/questions/24354119/) [2] [http://stackoverflow.com/questions/3131518/](http://stackoverflow.com/questions/3131518/) [3] [https://support.cloudflare.com/hc/en- us/articles/200168256-W...](https://support.cloudflare.com/hc/en- us/articles/200168256-What-are-CloudFlare-s-caching-levels-) [4] [http://stackoverflow.com/questions/23603023/](http://stackoverflow.com/questions/23603023/)

<comment><USER15> I haven't looked into the code yet, but the service worker has almost complete control over network requests and caching. It can calculate the correct response for a url (e.g. based on this delta encoding system), cache it, and use it in place of or alongside network requests in order to respond to a browser request.

</comment></comment><comment><USER16> Here is a Python serverside implementation:

[https://github.com/alexcasalboni/sw-delta- python](https://github.com/alexcasalboni/sw-delta-python)</comment>


Talking sex, brains, and commitment with the best-selling scientist of love - <AUTHOR> http://nautil.us/issue/22/slow/ingenious-helen-fisher

<comment><USER2> This is maybe the most frustrating way to display some videos. My god.

Cool stuff though :).</comment>


'Barnacle' car windscreen clamp sparks student fury - <AUTHOR> https://www.bbc.com/news/technology-51133807 <comment><USER3> I'm surprised this stuff is still legal, especially since even chalking tires was ruled to be trespassing and a illegal search, and looks like this is a public school too so government ran. Some of the law school students should get together and file a section 1983 civil rights lawsuit, use it to pay off some of that student debt!

[https://www.nbcnews.com/news/us-news/chalking-tires- enforce-...](https://www.nbcnews.com/news/us-news/chalking-tires-enforce- parking-rules-unconstitutional-court-finds-n997326) or [https://www.npr.org/2019/04/23/716248823/court-says-using- ch...](https://www.npr.org/2019/04/23/716248823/court-says-using-chalk-on- tires-for-parking-enforcement-violates-constitution)

So now cities have to use licence plate recognition cameras and location GPS data to see if a car moved or not since chalking is illegal, but I'm sure cities are unaware of this and still are illegally chalking cars - <USER2> someone sues and get a huge payout. Then some cities will arrest people because their children drew on the sidewalk using chalk, considering it vandalizing even though it washes off in the rain.

<comment><USER4> OU is in a shambles right now, from an administrative standpoint, due to a double-transition of its leadership.

I'm willing to bet that the parking enforcement people never questioned the legality of the device, asked few questions about its legality, and assume its existence is proof of its legality.

</comment></comment><comment><USER5> "One poster on social news site Reddit claimed he had been able to extract a mobile network Sim card from one of the devices, and used it to access the internet for free."

When life gives you lemons, dig the sim cards out of them and get free internet.

</comment><comment><USER6> A car has a VIN. It likely has a plate, registration, and title. The owner should be easy to determine. With that, go to court.

The devices risk damaging cars and they risk creating emergency situations by disabling cars.

<comment><USER3> Yep, I seen people in a RV group talk about these. Some Walmart stores are using them on truck drivers and RVers who stay over the night. I believe it's a contractor Walmart hires though, not actual Walmart employees. I think it's insane a private company is even allowed to do this stuff, and some people said they'd yank it off and if their windshield cracked put a claim in with the companies insurance company.

However I don't think private booting or these devices is legal in every state or even varies by city in some states. Someone was sleeping inside, woken up after they put on the device and they wanted 500 dollars to remove the device. I'm surprised some truck driver in the South like Texas that's more gun friendly doesn't get woken up thinking he's being robbed and ends up shooting one of these contractors by mistake. There's stories where people have mistakenly woke up and even shot their own family who came home too late thinking someone was breaking in, so surprised this hasn't happened yet if someone is really tired and startled not realizing what's happening yet. Probably would be a big highly profiled national case if something like that happen though, and people who aren't a fan of all this parking stuff probably would side with the trucker, so doubt they'd be impartial enough. I don't think parking enforcement would be a job I'd enjoy, probably so many angry people daily, and not sure if I'd want to work alone at night in a dark parking lot waking up people, especially with the trucking shortage.

Found an article about this: [https://www.truckingtruth.com/news/Article-94/barnacle- boot-...](https://www.truckingtruth.com/news/Article-94/barnacle-boot-device)

<comment><USER7> > I think it's insane a private company is even allowed to do this stuff

I wonder if this private enforcement of law goes both ways - can a car owner barricade Walmart's entrance to force Walmart to pay them what they've unilaterally decided they're owed?

<comment><USER8> What Walmart is doing may be legal though if they own the parking lot. Deciding to block an entrance could be illegal, though I'm not aware of any case law around it.

</comment></comment></comment></comment><comment><USER9> Here's how to get it off , and get free internet (Why this is trending)-

[https://twitter.com/saallyjohnsonn/status/121719070339206758...](https://twitter.com/saallyjohnsonn/status/1217190703392067584)

<comment><USER10> Wouldn't it be trivial for the company to track where the SIM is being used to find out who's done this?

</comment></comment><comment><USER11> Another way to destroy a program like this would be to vandalize barnacles wherever you see them. Nobody is going to report you (because everyone hates them). The car owner will be assumed responsible, and held hostage for the damage done to the barnacle.

Then sit back and watch the extortion lawsuits fly. The program won't last long.

</comment><comment><USER12> If someone takes out the SIM to use it for internet that they didn't have a right/permission to use, that sounds a lot like theft of services. It's usually a criminal offense, and that could follow someone around for years to come. Plus, $2000+ in legal defense costs. I wouldn't risk it.

</comment><comment><USER13> I'm failing to understand what exactly sparked the fury. To me this sounds much nicer than the alternative.

<comment><USER14> The article is not entirely clear, but I suspect that the threshold to deploy the Barnacle is lower than for towing. For example, would they really call the tow truck for a car with three unpaid tickets? And if a vehicle is parked blocking a fire lane or an entrance, they'll still have to have it towed, so there's not a one-to-one correspondence between the use cases.

</comment></comment><comment><USER15> Students pay 30$ extra for usage of the "barnacle" in addition to the fine.

<comment><USER16> I imagine that's cheaper than paying for the towing fee that's the alternative?

<comment><USER17> > Mr Dougherty said improvements had since been made to the design of the > barnacle, and said 40,000 had been deployed and returned without incident.

Sounds like they make it up in volume. I doubt they'd get a tow truck out there 40000 times.</comment></comment></comment>


3.5 Years, 500k Lines of Go - <AUTHOR> https://npf.io/2017/03/3.5yrs-500k-lines-of-go/ <comment><USER3> I'm 3.5 years into using Go exclusively as well, and this rings very true to me with regard to generics:

> Interfaces are good enough 99% of the time.

Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that.

Generics could allow for some nicer (and safer!) nil handling and error checking, but I think the benefits-vs-complexity are less clear than with generics for data structures.

I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers -- especially for a new language where hiring experienced devs is next to impossible. The ease of onboarding is reason enough for businesses to consider Go as over an org's life a _lot_ of time will be spent (wasted?) onboarding.

Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve.

> And I don't mean interface{}. We used interface{} rarely in Juju, and almost > always it was because some sort of serialization was going on.

This has been my experience as well. Whenever I hear someone complaining about interface{}, I wonder what they're doing. I think it's often people used to having generics or a dynamic language trying to follow similar patterns in Go and not considering alternative patterns.

I've never used a language that didn't lack type information at the edges (where serialization occurs). Even using strongly typed serialization (eg Protobufs) in a language with strong type features and patterns (eg Java) I always see a fair amount of glue code converting from "weaker" serialization types to stronger internal representations.

As long as those edges are architected to be easily testable (even fuzzable!); I don't see it as a problem. You have to convert from bytes-on-the-wire to typed variables somehow.

<comment><USER4> > Any language features which increase cognitive overhead had better offer > some extremely compelling benefits to outweigh an increased learning curve.

This is a common misunderstanding that occurs (I think) because most people only know C++-, Java-, and C#-style generics, which can be conceptually complicated, because of the often tricky interactions with the type system (or, in the case of C++, the use for metaprogramming).

In contrast, module-based genericity (SML, OCaml, Ada, Modula-3) is conceptually pretty simple, as it avoids complicating the type system. Its main downside is (relative) verbosity, but Go has never really eschewed verbosity.

<comment><USER5> It struck me the other day that when using Go codegen tools which generate packages based on a template, e.g. [0], the Go developer is doing manually what the OCaml compiler will do with functors at compile-time. The concepts are fundamentally the same...the effort just happens in different places.

[0]: [https://github.com/cheekybits/genny](https://github.com/cheekybits/genny)

<comment><USER6> They're very different. Generics in languages that have them are _typed_ —you have to declare up front the methods that your generics support. That's the entire thing that makes ML functors functors.

By contrast, generics in languages like C++ and D, as well as the code generation tools for Go, are _untyped_ —you can call whatever functions you want on your types, and if it doesn't work it fails at template instantiation time. This causes the confusing template errors people see in C++.

<comment><USER5> You are, of course, absolutely correct: compile-time awareness of semantics vs just syntax is an important difference.

I guess the point I was getting at – though improperly phrased – was that if current Go tooling is similar to templates, and templates are similar to functors (in that you're instantiating both but the latter have additional checks for correctness), then perhaps module genericity wouldn't be as tough a sell to the Go team/community.

</comment></comment></comment></comment></comment><comment><USER7> > The first was assuming forward slashes for paths in tests. So, for example, > if you know that a config file should be in the "juju" subfolder and called > "config.yml", then your test might check that the file's path is folder + > "/juju/config.yml" - except that on Windows it would be folder + > "\juju\config.yml".

Wait what? I thought this was solved ten years ago [https://en.wikipedia.org/wiki/Path_(computing)#MS- DOS.2FMicr...](https://en.wikipedia.org/wiki/Path_\(computing\)#MS- DOS.2FMicrosoft_Windows_style)

<comment><USER8> Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this.

I find myself very productive in Go, I've written a lot of it now, but I do also find myself writing more code than I thought I would, having had some expectations set by Python and Java. Go's philosophy seems to avoid doing something which can be done incorrectly, and instead punting it to developers. It's not always as simple as simply replacing forward and backward slashes.

<comment><USER9> > Go gives you the tools to handle this, but you have to do it yourself. > filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for > this.

You're missing the point—it's unlikely that you _need_ to do anything at all; the Windows APIs handle forward slash as a path separator just fine.

And on that note, for any MS employees reading now and who write READMEs and other docs for projects with publicly released code in this "New Microsoft" era, please default to using forward slash for the paths in your code snippets, instead of backslash. There's hardly any reason not to. (Unless you're using the command prompt—but you guys are a pointy clicky bunch and don't like the CLI anyway, right? Even so, you have PowerShell.)

So you can drop practice of writing up separate "For Windows users" and "For Mac and Linux users" instructions that differ only in the type of path separator used. Just use plain ol' slash.

Please tell your colleagues to do the same.

<comment><USER10> This is about what the Windows API reports when you ask it what the path is of a file. Sure, inputs work with slash. Comparing outputs, which was the example I gave, does not.

<comment><USER9> I take it you're referring to the part that VMG quoted. Thanks for providing context.

This doesn't change my response to oppositelock.

</comment></comment></comment></comment></comment><comment><USER11> I happened to believe that a language should have one style.

You want a functional language? Use it.

You want a procedural language? Use it.

You want an OOP language? Use it.

They're all good, but not in one language.

For example, you like FP idioms, and program everything with maps.

I like for loops.

You have to fix my code one day I'm on vacation.

You think that it's ugly, and rewrite it as a map.

I get back, bug comes up, I rewrite it back to for loops.

Repeat.

Go showed how to finally end indentation wars, maybe it can show how to end style wars.

<comment><USER12> Even though I've written more ruby than anything else over the last decade, I have to agree with this. Ruby is nice OO language, but it's unabashedly multi- paradigm, and that leads to a lot of mess when you get a team with varying backgrounds the result is potentially a byzantine mix of procedural, object- oriented and functional styles.

<comment><USER13> When you are in a big project a multi paradigm language seems to be the only way for introducing new styles. In the stuff I am working on I can't just switch to a new language. I agree that this can create a mess though.

<comment><USER12> Absolutely, but it's such a double-edged sword. All else being equal, I love ruby, and when it comes to shitty legacy codebases, you can do worse than ruby because of the power at your disposal to work around problems. On the other hand, it's not that hard in ruby to make something that is so thoroughly fucked that there's no reasonable option but to nuke it from space.

The beauty of Java, Go and Haskell (never thought I'd use those 3 in the same sentence) is that you really have to work to fuck things up that badly.

</comment></comment></comment></comment><comment><USER14> I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity.

> Because Go has so little magic, I think this was easier than it would have > been in other languages. You don't have the magic that other languages have > that can make seemingly simple lines of code have unexpected functionality. > You never have to ask "how does this work?", because it's just plain old Go > code.

That lack of magic and his comparison to C# sounds like a really good mix.

<comment><USER15> > That lack of magic

I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

<comment><USER10> one of the things that go eschews is operator overloading.

        a := b + c

What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory.

In C#, you can overload operators, so the + could in theory do anything. And what's bad about that is that it is deceptive. It's easy to miss the fact that this line might actually be doing something complex.

It also means that if someone is looking at your code, they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code.

This is one of the pieces of magic that I'm glad go doesn't have.

<comment><USER16> Hogwash. In a language with operator overloading, this would be something like `a.assign(b.plus(c))`. Which really doesn't tell you more about what go on under the wraps than the operator form.

What can be confusing is what the meaning of `+` (or `plus` is). In some case it can be fairly obvious (e.g. concatenating sequences), while in other not so much. Operator overloading is nice, but has to be used tastefully (like every abstraction or language tool).

<comment> grey-area In C#, you can overload operators, so the + could in theory do anything.

 _What can be confusing is what the meaning of `+` (or `plus` is)_

QED

<comment><USER16> Any function can do anything. I can write a function called "read_from_file()" that doesn't read any files.

Amazing, I know.

Also please actually read the comment before replying:

> Operator overloading is nice, but has to be used tastefully.

<comment> grey-area The point the OP made was that operator overloading is not nice - it means that any operator (not just function) can do anything. It makes code harder to read and reason about.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I am really enjoying working with go on smaller projects and it is this philosophy that has made understanding the code much easier.

But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code?

<comment><USER10> functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods.

I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

<comment><USER18> And go can not write abstract functions and methods.

I can not write a function dealing with arbitrary values.

Somethind I'd do in Java with

        public static <T extends IIncrementable> T increment(T val) { val.increment(); return val; }

is impossible to do in Go.

You can not abstract over types, and write metric fucktons of duplicated code. I've tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times, once for every type. Fixing bugs became a nightmare.

<comment><USER19> > I've tried porting some of my Java code, and it quickly grew to some classes > being duplicated hundreds of times

Who would have thought. Maybe a rewrite would have been more appropriate.

<comment><USER18> Porting meant rewriting here.

But I still ended up with the same classes replicated hundreds of times.

Polymorphic code is not possible in any other way in go – you always have to duplicate the code.

<comment><USER19> I'm sorry it went badly then.

Your example intrigues me, isn't an interface enough?

Is what bother you that the return value won't be typed T but IIncrementable in go?

<comment><USER18> Yes, exactly. This is an actual issue.

My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts.

So, the library now gets these functions, and does all the filtering on other threads.

So either I have to replicate the entire async code for every type, or I can't keep type safety.

<comment><USER20> Don't keep type safety then. Think of Go as half-way between Python and Haskell in that respect. Types are great when they're useful, but they're not _required_.

<comment><USER18> If you're serious, that's... the worst solution I've heard yet.

That's the same mistake C did with void _, Java did with Object and corrected with generics in 1.5, just called interface{} this time.

And while with python and Java, even if I circumvent the type system, I can still use annotations (see typed python, or JetBrains @Contract, Google's @IntRange, etc), with Go I have nothing of that sort.

Types are useful to provide safety, if your type system has to be turnt off, then I am losing all that safety, and might as well code in PHP (although they _also* saw that mistake, and are fixing it now, with 7.0 and later).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Great point about time. At work we've adapted github.com/WatchBeam/clock and it's helped a lot.

Thanks for blogging about your work on juju! Despite Go already being five years old, many of the patterns around building large applications are only emerging now.

<comment><USER22> Go was released in 2007, it's 10 years old. Rust is closer to be 5yo, it's 7yo according to wikipedia.

<comment><USER23> It only became stable in mid-2015.

[https://blog.rust-lang.org/2015/05/15/Rust-1.0.html](https://blog.rust- lang.org/2015/05/15/Rust-1.0.html)

<comment><USER10> Comparing 1.0's is a much better comparison, except in cases where there was huge adoption before 1.0.

<comment><USER23> I wouldn't say rust was hugely adopted before 1.0 (not that it's hugely adopted after, either).

<comment><USER10> Yes, sorry, wasn't saying that either Go or Rust were an exception, just trying to forestall the inevitable "but what about X thing that was used by everyone and is still 0.9" :)

For Go vs. Rust, I think a comparison of 1.0 releases is perfect.

</comment></comment></comment></comment></comment></comment><comment><USER24>
        always always checking errors really makes for very few nil pointers being passed around

If your developers always always remember to write error checks, they probably also would have always always remembered to write NULL checks.

</comment><comment><USER25> Are generics really that big of a thing if you got structural typing?

I mean, you don't have to implement all the interfaces explicitly, you just have to get your structure right and be done with it.

Am I missing something?

<comment><USER26> I think generics would mostly be useful for container types, like putting methods on slices (like .map) without caring what's inside.

<comment><USER27> You might be interested in my side project: [https://github.com/lukechampine/ply](https://github.com/lukechampine/ply)

IMO when people say they want generics in Go, they really just want a few functional-style methods and functions on slices (e.g. map, filter, reduce methods, and functions like sort, reverse, repeat). So I wrote a compile-to-Go language that allow you to write "Go code" that also has those things.

One of the things I've found, though, is that Go's first-class function syntax really harms the elegance of these sorts of constructions. For example, compare:

        // square a slice of ints in Go
        for x := range xs {
            x *= x
        }

        // square a slice of ints in Ply (morph == map)
        xs.morph(func(x int) int {
            return x*x
        })

When really, we want something like:

        xs.map(x => x*x)

I think it's possible to achieve the latter without having to write a new lexer/parser/typechecker from scratch, but for now I'm avoiding adding any new syntax.

<comment><USER26> Wouldn't

        xs.map((x int) int => x*x)

be simple desugaring without messing with the type system?

<comment><USER27> Perhaps, but you aren't saving a ton of typing if you still need to specify all the types. I think you can get away with

        xs.morph(x => x*x)

because you know that xs is a slice of ints, so x must be an int, and that means x*x is an int, so the lambda has the right type signature.

As far as I can see, there are two potential annoyances with this approach: you have to explicitly cast constants sometimes (e.g. uint64(3) instead of just 3), and you have to explicitly cast values if you want to return an interface (e.g. io.Writer(file) instead of just file). But these cases are rare enough that I think the tradeoff is worth it.

</comment></comment></comment></comment></comment><comment><USER28> What do people think about the future of Juju?

<comment><USER29> For automation of deployments we prefer ansible (ex. it's agent-less)

For container orchestration it's clear that kubernetes is the winner (if you have k8s deployed you don't need juju)

For managing the whole thing manage iq have much to offer.

<comment><USER30> I like Ansible and use it for deploying vagrant setups and such but I've found quite a few things broken enough that I'm wary of using it to do deploy production stuff for quite a while I had issues with apt: so much so I ended up using shell, last time I wrote a new playbook they had resolved that though so things do get fixed.

</comment></comment></comment><comment><USER31> 3542 files

540,000 lines of Go code

65,000 lines of comments

So on average only 170 lines per file, including 17 lines of comments.

Are this normal ratios ?

<comment><USER32> I think so? Assuming a regular function (a method should do one thing and one thing only) is about ~20 lines, we're looking at ~6 functions (170 lines - <USER2> comments - about 15 lines of newlines, imports and so on = 130-odd).

Six functions sounds very reasonable to me.

</comment></comment><comment><USER33> Does anyone know where this developer is going after Canonical or why they left? It seems like they got to work on a nice project while there. Maybe that's another blog post though. It piqued my curiosity I guess.

</comment><comment><USER34> Is it too late to queue the joke about it being 500k lines because the lack of generics and the resulting code-generation?

Reading about projects with 100+ types of collections can certainly lead you to think so.

</comment><comment><USER35> Wonder how long does it take to build juju?

<comment><USER36> dave cheney has been tracking juju build times since the regression in the compiler when it was rewritten from C to go:

older article here: [https://dave.cheney.net/2016/04/02/go-1-7-toolchain- improvem...](https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements)

spreadsheet: [https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD...](https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD29j5LRb96QZC4mZDn72gAE4/edit#gid=0)

<comment><USER37> Wow the latest revision is down to 140% of 1.4.3. I'm impressed.

</comment></comment></comment><comment><USER38> This entire piece sounds like the Blub Paradox made real.

[http://paulgraham.com/avg.html](http://paulgraham.com/avg.html)

It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language's warts as "simplicity".

Also: 20 bonus blub points for pulling the old 'I don't need generics, therefore NOBODY does' gambit.

<comment><USER39> I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".

<comment><USER40> Over time, I've come to notice that once any online forum reaches a certain critical mass of programmers, nearly any mention of a specific programming language will devolve into a flamewar about that language.

I find it frustrating, but I also suspect that it's been that case since approximately forever ago. One day I plan to don a flame retardant suit and wade into Usenet archives to see if programmers were as prone to language flamewars 30+ years ago as they are now.

I'm guessing the answer is probably yes. :)

<comment><USER41>
      ... if programmers were as prone to language
      flamewars 30+ years ago as they are now.

      I'm guessing the answer is probably yes. :)

Your guess is spot on. Not only languages (C vs Pascal, "why doesn't anyone use Ada?"), but probably best remembered for the vi vs emacs crusades. Though about 20+ years ago there were some pretty heated exchanges regarding OOP which seem to still smolder to this day (see HN history for evidence :-)).

There's a reason why Godwin's law[0] came about :-D

0 - [https://en.wikipedia.org/wiki/Godwin%27s_law](https://en.wikipedia.org/wiki/Godwin%27s_law)

</comment></comment></comment></comment><comment><USER42> And half are from dependencies? ;)

<comment><USER43> Read the article:

 _As of this writing, the main repo for Juju,[http://github.com/juju/juju](http://github.com/juju/juju), is 3542 files, with 540,000 lines of Go code (not included in that number is 65,000 lines of comments). Counting all dependencies except the standard library, Juju is 9523 files, holding 1,963,000 lines of Go code (not including comments, which clock in at 331,000 lines)._

<comment><USER42> It was a joke.

</comment></comment></comment><comment><USER44> I think the author just wan to said: choice Go is exactly a mistake.

<comment><USER10> <_< >_>

No.

Go was a good choice. The project benefited from it, both from a hiring perspective and from a technical perspective. If I were in charge, I would make the exact same choice again.

Juju lives exactly in Go's sweet spot. A networked server worked on by more people than you can fit around your dining room table. Not every project would benefit from Go, but this one certainly did, IMO.

</comment></comment><comment><USER45> Off topic rant: I don't know much about the details of godeps hash file but I do wish that there were a better infrastructure for merging contents of various file formats. Built into git or shipped as a separate repository. I wasted too much time merging vcxproj.filters files just because in its XML representation one item of a sequence of folder assignments occupies 3 lines (opening tag, contents, closing tag) instead of having everything on one line. Similar problems with JSON files when new items added concurrently to the end of the array.

<comment><USER46> I found a program someone wrote called sortxml that will prettify and sort XML files. It's written C#. Might be possible to run it on Linux also, or to find another similar program for Linux that will. I'd investigate further if it wasn't for the fact that I rarely work with XML files.

[https://github.com/kodybrown/sortxml](https://github.com/kodybrown/sortxml)

You may be able to write a small wrapper script that does the following: For each filename passed as argument to your script you will run sortxml on it and store the result in a temporary file, then once you've done so for all files, you pass the sorted files to an existing merge tool such as for example meld, kdiff3 or vimdiff.

Let's say that you name your script mergexml.bash and that you put it in ~/bin/. Then it should be possible to first git merge as usual but when a conflict arises in an XML file, you will run something like

      git mergetool -t ~/bin/mergexml.bash example.xml

And your script will have simplified the process.

For bonus points, you might write an unsortxml program that your script will call at the end to rearrange the nodes and attributes to be in the same order as they were in one of the original XML files -- the user would be prompted to select which of the original XML files to use for ordering the nodes and attributes.

I haven't tested this of course, otherwise I'd probably have actual code to share for it but I think something like what I've outlined above should work.

<comment><USER46> Here's an extended example.

      mkdir -p ~/tmp/xml-merge-example
      cd !$
      git init .

      cat > example.xml <<EOF
      <?xml version='1.0'?>
      <hurr durr='hello'/>
      <durr hurr='world'/>
      EOF

      git add .
      git commit -m "Initial commit."

      git checkout -b alternate-reality

      cat > example.xml <<EOF
      <?xml version='1.0'?>
      <durr hurr='world'/>
      <hurr durr='hello'/>
      <foo reality='alternate'/>
      EOF

      git add .
      git commit -m "Alternate reality."

      git checkout master
      sed -i '' -e 's/hello/foo/' -e 's/world/bar/' example.xml

      git add .
      git commit -m "Hello foo to the world bar."

      git merge alternate-reality

The attempted merge will result in the following:

      Auto-merging example.xml
      CONFLICT (content): Merge conflict in example.xml
      Automatic merge failed; fix conflicts and then commit the result.

For a quick PoC, let's create a little script that will echo the arguments that was passed to it and then exit with failure. The real script would work as outlined in the parent comment and would exit with success at the end as long as the merge worked out.

The t argument to mergetool works a bit different than I thought, but not by much -- the tool must be referenced by name and the corresponding mergetool.<tool>.cmd must have been set. In the command you use the variables $BASE, $LOCAL, $REMOTE and $MERGED as explained in [https://git- scm.com/docs/git-mergetool#git-mergetool--tlttoo...](https://git- scm.com/docs/git-mergetool#git-mergetool--tlttoolgt) . This allows tools with different argument ordering, flags and such to be used.

Let's write the PoC script

      mkdir -p ~/bin
      cat >~/bin/mergepoc.bash <<'EOF'
      #!/usr/bin/env bash

      echo "$0: WARN: Proof-of-Concept" 1>&2
      echo "$0: INFO: Arguments: $@" 1>&2
      exit 1
      EOF

      chmod 755 ~/bin/mergepoc.bash

and define the mergetool cmd

      git config mergetool.mergepoc.cmd '~/bin/mergepoc.bash --base "$BASE" "$LOCAL" "$REMOTE" -o "$MERGED"'

and tell git to trust the exit status of this tool

      git config mergetool.mergepoc.trustExitCode true

Then we run it.

      git mergetool -t mergepoc example.xml

Result (with an additional line-break inserted in order for to avoid having the contents shown here scroll sideways):

      Merging:
      example.xml

      Normal merge conflict for 'example.xml':
        {local}: modified file
        {remote}: modified file
      /home/erikn/bin/mergepoc.bash: WARN: Proof-of-Concept
      /home/erikn/bin/mergepoc.bash: INFO: Arguments: --base ./example_BASE_4020.xml
        ./example_LOCAL_4020.xml ./example_REMOTE_4020.xml -o example.xml
      merge of example.xml failed
      Continue merging other unresolved paths [y/n]? n</comment></comment></comment>


New iOS control: Pull-to-sort control for UITableViews - <AUTHOR> http://rme-ideas.com/blog

<comment><USER2> I really dislike this UI concept. It is completely non-discoverable and when paired with "pull to refresh" it is hard to guess what the pull down gesture do.

Drawer is a better concept IMHO - it informs the user that there are _some_ actions and the user can check them out to see what they do.

Or maybe I am wrong and people will love to pull down every list just to discover what is hidden there.

<comment><USER3> PTR is pretty common on iOS, so users are pretty well trained to do just that. It's rare enough on Android that it's usually a bad idea.

On the other side of the coin, you have the Menu button on many Android devices that pops up ancillary actions that don't fit on the screen. I can't tell you how many bug reports I get for functionality that I've buried in there, but if I was paid a dollar for every one, I'd be rich. And this is a control that has been around for five years...</comment></comment>


Graphene Will Change the Way We Live - <AUTHOR> http://bigthink.com/ideas/24381

<comment><USER2> While I really like all the properties of this wonder substance, I'd be more cautious about the possible negative effects. With plastics we have a big problem with pollution (Big Pacific Garbage Patch comes to mind), and toxicity (BPA, etc).

What will be the problems with graphene?

Don't get me wrong, I want all the positive things it is promising, but I am worrisome that we are going to head-rush into it like it happened with pesticides, plastics, and others.

</comment><comment><USER3> Who controls the patents?</comment>


How to resign: by code - <AUTHOR> https://github.com/sbeckeriv/ruby-resignation-letter/blob/master/resignation.rb

<comment><USER2> Now with python!

</comment><comment><USER3> LOL..</comment>