How to Get Past Customs Without Giving Up Your Digital Privacy - <AUTHOR> https://www.wired.com/2017/02/guide-getting-past-customs-digital-privacy-intact/ <comment><USER2> It's really depressing that this kind of thing is even needed for the US. As a citizen with a lot of privileged status, I'd personally be pushing back a lot if any US CBP person ever asked me for anything beyond proof of citizenship and the bare minimum to show I'm not carrying contraband. I'd consider standing up to that as a way to help other people who can't as easily stand up to it. On the other hand when I'm visiting a foreign country on a visa, I'm in a similarly disadvantaged position.

(As an aside, if anyone in security is ever looking for a trustworthy and accurate journalist, I strongly endorse Andy Greenberg; consistently good at respecting "on the record" vs. "off the record", and he actually asks good questions.)

<comment><USER3> > I'd consider standing up to that

What does that even mean? They'll detain you or deny entry. Then what?

<comment><USER2> I'm a US citizen. Aside from "is this actually Ryan Lackey, the US citizen?", immigration has no power to keep me out of the country.

"Do you have reason to believe I'm someone other than the US Citizen in this passport? Please articulate your specific reasons for concern." is itself a pretty solid validation of "this guy is 1) a US citizen 2) knows the law 3) is likely to have >50 lawyers as friends and will pursue the matter happily. I'm really polite/friendly with ICE/CBP -- usually all I get is "welcome home", very infrequently they ask "where were you?" \-- but in principle they can hassle people.

Customs has some additional power -- do they believe you're transporting contraband -- illegal items, untaxed items, or dangerous items (agricultural contact). But since I never travel with illegal items, and generally have everything very nicely organized and minimalist, the only real thing they could claim is "you have digital files we want to access", and that is 1) an emerging area of law and 2) exactly the battle I want to fight. In general the law is on the side of citizens not turning over data at borders, although it's nowhere near as settled as most other things.

<comment><USER4> >I'm a US citizen. Aside from "is this actually Ryan Lackey, the US citizen?", immigration has no power to keep me out of the country.

This is a dangerously simplistic view of the US security apparatus that will almost certainly backfire on you if you actually try to test it out.

If you happen to resist inquiries in any meaningful way, there's a significant chance that they will seize everything you're carrying, find a means to force you into unlocking your digital devices, then hit them with a fine-toothed comb until they find enough to a straw-man justification to continue detaining you and making your life hell. A few sarcastic or otherwise disestablishmentarian remarks to a CBP offer it all it takes to turn a minute- long interaction into a days or weeks-long holiday in a detention cell.

And sure, the extent to which CBP has the right to pry into your digital life is still an emerging area of law, but in the status quo, things lean very much in CBP's (and whatever other law enforcement agencies they decide to pull in) favor.

Sure, if you're a US citizen, they'll likely need to _eventually_ let you in, but that doesn't necessarily mean that you're out of trouble at that point either. At the very least, you're now a strong candidate for continued surveillance, if not further sanctioning, depending on how the information collected during your re-entry to the country might correlate you with various 'risks to national security'.

<comment><USER2> I would be exceptionally surprised if they did anything beyond ~hours of detention and confiscating as much stuff as they possibly could to "investigate" (essentially as punishment).

</comment></comment></comment></comment></comment><comment><USER5> 2FA? With a mobile number? Did the author completely forget Snowden, and how all the major phone companies give NSA direct access? Did the author forget the broad NSA information sharing that Obama enacted just before leaving office? Even that damned Coast Guard can get your 2FA code now.

<comment><USER6> > Even that damned Coast Guard can get your 2FA code now.

Posting unsourced and absolutely false claims does not help anyone, honestly. I would even consider it harmful.

<comment><USER5> Before Snowden, they liked to call it tin foil hats.

[https://theintercept.com/2017/01/13/obama-opens-nsas-vast- tr...](https://theintercept.com/2017/01/13/obama-opens-nsas-vast-trove-of- warrantless-data-to-entire-intelligence-community-just-in-time-for-trump/)

One of those agencies is the Coast Guard. If the message crosses national boundaries, it's fair game.

[http://www.nytimes.com/2013/08/08/us/broader-sifting-of- data...](http://www.nytimes.com/2013/08/08/us/broader-sifting-of-data-abroad- is-seen-by-nsa.html)

And before you pass through customs, you are considered outside the country.

All legal. Checkmate.

Fortunately, I've just discovered that the SMS option isn't required on a Google account. Now you just have to remember to remove your travel yubikey from the account before you fly home.

<comment><USER6> Please review the post linked from the beginning of the linked The Intercept article, here: [https://icontherecord.tumblr.com/post/155766682978/fact- shee...](https://icontherecord.tumblr.com/post/155766682978/fact-sheet-on- eo-12333-raw-sigint-availability)

You'll see that SIGINT sharing is not a free-for-all in any manner, it is restricted. It seems dishonest to tell people the Coast Guard can use it to compromise SMS 2FA (I'd be far more worried about other countries compromising SMS 2FA in a close-access scenario, using an "IMSI catcher" or similar device to intercept the incoming message).

<comment><USER5> >You'll see that SIGINT sharing is not a free-for-all in any manner, it is restricted.

Before Snowden, we were told investigatory powers were "restricted" as well. Then we learned linux journal readers were put on watch lists as extremists, and system administrators are routinely targeted for compromise.

The point being, there's no _technical_ reason to stop them from intercepting the 2FA over SMS, so they will. That's been clearly demonstrated by earlier leaks. Those people weren't fired/jailed/etc. They'll just do it again.

<comment><USER6> > Before Snowden, we were told investigatory powers were "restricted" as well. > Then we learned linux journal readers were put on watch lists as extremists, > and system administrators are routinely targeted for compromise.

Again, I'm sorry but none of this is true at all. I could absolutely believe that a journalist misunderstood something they read in a leak and then made such a claim (Happened with most of the Snowden leaks), but that does not make it true.

> The point being, there's no technical reason to stop them from intercepting > the 2FA over SMS, so they will. That's been clearly demonstrated by earlier > leaks. Those people weren't fired/jailed/etc. They'll just do it again.

To the contrary. When you say "clearly demonstrated by earlier leaks" I believe you may be mixing up an inquiry made to NSA with regards to improper access to DNI (Or perhaps that was not supposed to be a public response and was indeed leaked? Not certain). Action was taken against these individuals who "tested the system" by trying to look up themselves and/or someone they knew, even if the system blocked the query from actually running due to the fact that they were prevented from targeting US persons.

I believe you are being genuine about your concerns, but again, it can be harmful to spread falsehoods when people reading these comments may not know better and could believe what you're saying to be true (Especially in a thread like this).

<comment><USER5> >Again, I'm sorry but none of this is true at all.

[http://www.linuxjournal.com/content/are-you- extremist](http://www.linuxjournal.com/content/are-you-extremist)

It's you against the world here. Trying to rewrite history?

>I could absolutely believe that a journalist misunderstood something they read in a leak

Literally, the document title is "I hunt sys admins"

[https://theintercept.com/2014/03/20/inside-nsa-secret- effort...](https://theintercept.com/2014/03/20/inside-nsa-secret-efforts-hunt- hack-system-administrators/)

There's nothing to misunderstand. They used automated attacks on readers of Slashdot and LinkedIn.

[http://www.ibtimes.com/edward-snowden-reveals-quantum- insert...](http://www.ibtimes.com/edward-snowden-reveals-quantum-insert-nsa- gchq-used-fake-linkedin-slashdot-pages-install-spyware)

Compromising system admins is a routine part of their job. It's one way they collect private keys to decrypt internet traffic. That is an established fact from the Snowden leaks.

<comment><USER6> 1\. It is a false claim. Their evidence is an XKS configuration file which they decided to add unsubstantiated context to, not sure why. Linux Journal then appears to have responded as they trusted the reporting website to be telling the truth.

2\. The article you've linked contains no evidence to indicate "system administrators are routinely targeted for compromise" though. It contains evidence showing his methodology of accessing target systems by looking into the sysadmins who manage it (You are free to have your opinions on this practice of gaining entry to a target, but it is dishonest to change the context to indicate something being done on a wide scale).

3\. When you say "They used automated attacks on readers of Slashdot and LinkedIn" I would counter that the sentence is poorly phrased. If you mean "all readers of Slashdot and LinkedIn" then that is false. If you mean specific employees at the targeted company, who were targeted and had their connections MitMed, there does indeed appear to be evidence that it was used as a successful access method on the specific target(s). If your opinion is that you do not like IC agencies using CNE, you absolutely have a right to that opinion of course. My only issue with that claim is that the phrasing could be misinterpreted.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Step 1: Don't travel to the U.S.

</comment><comment><USER7> step 0: use a password manager. step 1: use randomly generated passwords for every account in that manager. step 2: neglect to bring that password file, or any means of accessing it, across a border.

Them: Give us your password! You: I literally cannot. Your move!

<comment><USER8> Them: Ok, we're denying you entry to this country.

Alternatively, if you are a citizen:

Them: We'll just keep these devices, then. When you get the password maybe you can get them back after we've searched them. Just wait here for 6-24 hours while we do our alternative background check.

<comment><USER2> If you're a US citizen and are harassed by CBP at the border (and you know you're not doing anything wrong), you should stand up for your rights.

<comment><USER8> Sure, I'm just saying that they aren't going to just be impressed with your awesome op-sec, they are going to seize your devices as evidence and harass you to the full extent that their inappropriately broad powers allow. If you're not ready for that to happen, probably best to make other arrangements.

<comment><USER2> Yeah, and I'm saying that if you can do this, you should, to help the many people who can't. I'd get more lulz value out of a $250 chromebook being taken for 6mo on bogus grounds than the cost of the chromebook.

It's not a solution (since they can easily pre-sort citizen vs. non-citizen, and treat one group dramatically worse, even beyond the legal or threat-model requirements), but it's a start.</comment></comment></comment></comment></comment>


Ask HN: How do you use Gmail? - <AUTHOR>

Based on my newsletter subscribers, most HN members use Gmail (last time I checked it was 63%, and that only is counting gmail.com addresses). Thought it would be interesting to see how others use it.
Some ideas - How do you use filters? What plugins/apps/scripts do you use? Workflow or automation that you use? Hacks/tricks?
jgrahamc's article today is what got me thinking about this: http://blog.jgc.org/2010/09/how-i-handle-my-mail.html http://news.ycombinator.com/item?id=1735262 <comment><USER2> My inbox is fairly small usually, and most of my email traffic comes from mailing lists, which are easy to filter.

Due to that, I'm only using Nested Labels from Labs, so my labels look like "lists/foo/bar" - and my filters just label appropriately.

No other plugins, apps or hacks, it's fairly simple. Long gone are my days of receiving a lot of mail directly addressed to me (thankfully, if I may add).

</comment><comment><USER3> I use gmail for POP/SMTP access through MS Outlook only. I like having Outlook and, if I couldn't use it w/ gmail, I would probably look elsewhere for an email address.</comment>


Ask HN: Bootcamp or Computer Science University Degree? - <AUTHOR> More and more people learn about programming in bootcamps and got software developer job right after. So is it still worth the time/money doing computer science at universities? <comment><USER2> It's not are "either or" question. You can and probably should do both. Formal education will give you the insights to understand the mathematical principles on which the profession is based.

And a couple of bootcamps will give the currently in demand techniques and tools.

It's the difference between being an "<X> programer" where X is your flavor of the month technology. And a "Software Engineer"

<comment><USER3> I realized that I have a weird antipathy towards bootcamps in my mind a while back, so genuine question: what's in modern bootcamps as they are usually run that you couldn't pick up yourself more efficiently (either by doing a few toy projects before starting a job or in the first few weeks if it's a new-to-me stack)?

I see ads for bootcamps that want people to pay them for a course on some popular language or web stack all the time and I'm never quite sure why anybody would go for these / why you'd even want a course on how to be an "<X> programmer" in your resume.

</comment></comment><comment><USER4> Yes. Not for the immediate "get a job" scenario... in that case you don't need either, you just need skills... but the comp sci route will give you exposure to high level topics you will need if you want to have a _career_</comment>


Human Hibernation Is a Real Possibility - <AUTHOR> https://www.theatlantic.com/health/archive/2020/01/human-hibernation-real-possibility/605071/ <comment><USER2> >The squirrels Drew studies, for example, curl up into little balls and plummet from 99 degrees to 27. This drops their basal metabolic rate by about 99 percent.

Not sure if this is meant to be C or F, but either the squirrels are boiling hot normally, or frozen solid while hibernating.

<comment><USER3> Fahrenheit

From the study:

> ...their core body temperature falls to as low as −2.9 °C, or 2.3 °C below > the equilibrium freezing point of their body fluids. At these body > temperatures, arctic ground squirrels avoid freezing by supercooling, which > refers to the metastable state that fluids enter when cooled below their > crystallization temperature in the absence of catalysts of freezing, or > nucleators.

<comment><USER4> Does that mean that if you kick a hibernating Arctic ground squirrel It will freeze solid?

That sounds both fascinating and horrible at the same time.

</comment></comment></comment><comment><USER5> Feels kind of misleading to say that humans lack no organ for hibernating, and then bring up at the end that hibernating animals have a different bowel structure to prevent sepsis.

<comment><USER6> Also the bit about "Astronauts would need a tube surgically implanted in their abdomen to remain fed during their hibernation"

<comment> apk-d I'm confused about that part. There's cases of people living without food for many months, given enough stored body fat. I'm assuming there's a reason for the surgical approach (you still need water and supplements), but I think the article isn't clear on what it is.

</comment></comment></comment><comment><USER7> Let's say you hibernated 4 months each year starting at age 35, if you live to 85, that would be an extra 16 years of wall clock life. A person born in the year 2000 could live past 2100, or at least until there are more advanced therapies available. I could see hibernation retreats becoming a big business if this technology works out.

<comment><USER8> Imagine going into hibernation at the beginning of february this year and waking up now.

<comment><USER9> Perfect timing. The ski slopes all closed mid March, and the beaches have been re-opened. If you have the cash to sleep for 4 months, you probably spend most of your time doing activities and the economic impacts are trivial.

If you live in a country where these things aren't available to you, well yeah, sucks to be you in that situation.

</comment></comment></comment><comment><USER10> Interesting read. I read an article years ago about early humans in Europe who did indeed hibernate or slept a few months of the year when it was very cold and no food.

<comment><USER11> This one? I think it was posted to HN a few years ago.

[https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1117993/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1117993/)

<comment><USER10> There was another that dealt with prehistory as well...

</comment></comment></comment><comment><USER12> I was hoping to find a clue to why I can sleep indefinitely, at least 70 hours straight. It feels like what I imagined hibernating to be.

I still have my OEM bowel tho; I guess my super sleep isn't actual hibernation.

</comment><comment><USER13> Maybe you could, but would you want to?

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

</comment><comment><USER14> So that scene in The Abyss was not so far-fetched after all.

<comment><USER15> Lindsey's drowning and hypothermia or the liquid breathing rat?

<comment><USER14> I was referring to Lindsey's drowning/hypothermia in this case.</comment></comment></comment>


To be a master of metaphor - <AUTHOR> http://sub.garrytan.com/to-be-a-master-of-metaphor <comment><USER2> ah, but to be the master of all 4 grasshopper... Simile, metaphor, allegory, parable [http://azwritingcoach.blogspot.com/2011/06/simile- metaphor-a...](http://azwritingcoach.blogspot.com/2011/06/simile-metaphor- allegory-parable.html)</comment>


The world's smallest self-replicating program - <AUTHOR> http://www.ioccc.org/1994/smr.hint

<comment><USER2> phiX174 virus - one of the world's smallest self-replicating programs :-)

[http://www.ncbi.nlm.nih.gov/nuccore/NC_001422.1](http://www.ncbi.nlm.nih.gov/nuccore/NC_001422.1)

Enterobacteria phage phiX174 sensu lato, complete genome

5386 bp ss-DNA

<comment><USER3> Hehe funny that you mention phiX174 in the context of programming, that virus is amazing... Part of the reason phiX174 is so small is that it is "compressed" by having overlapping genes; in one area, three genes overlap in the same place! This is possible because there are 6 valid reading frames (direction and start point) for reading DNA: {forward or backward} x {address % 3 == 0, 1, or 2}.

In college I actually got to take part in refactoring that virus' genome into a decompressed version with no gene overlaps. And it worked! The decompressed version is still a functioning phage, and since there are no longer gene overlaps, future genetic engineers will have a much easier time modifying the phage as they see fit.

[http://www.sciencedirect.com/science/article/pii/S0042682212...](http://www.sciencedirect.com/science/article/pii/S0042682212004618)

<comment><USER4> That's pretty amazing. I'm guessing DNA compactness is a survival advantage for viruses, and that's how this emerged? Is gene overlap common in other species?

<comment><USER5> I would think the opposite may be true, given that compressed information tends to be more sensitive to error, than uncompressed.

<comment><USER6> Redundancy helps resistance to error, yeah. This thing could be quite easily damaged in transmission.

</comment></comment></comment></comment></comment><comment><USER6> The Makefile is the most interesting part: [http://www.ioccc.org/1994/Makefile](http://www.ioccc.org/1994/Makefile)

      smr: smr.c
      	@${RM} -rf smr
      	${CP} smr.c smr
      	${CHMOD} +x smr

Apparently, an empty file marked as executable will execute!

<comment><USER7> Because it's being interpreted as a shell script, I assume.

<comment><USER8> Without a hashbang it's actually interpreted as machine code, it just doesn't have any machine instructions.

<comment><USER9> No, without a shebang it is interpreted as a shell script.

<comment><USER10> Correct. A file will only be considered a binary executable if it has a proper header (ELF, Mach-O, etc) The default if no header and no shebang is to treat it like a shell script.

In fact, an empty executable file has been used to implement /bin/true on some old systems. Why take the added cost of a disk seek when just the information in the inode will do?

<comment><USER11> >In fact, an empty executable file has been used to implement /bin/true on some old systems. Why take the added cost of a disk seek when just the information in the inode will do?

why is this only on old systems? it seems very efficient.

<comment><USER12> What's more efficient is that most shells don't bother running /bin/true at all. "true" is just a shell builtin, so it doesn't need to spawn a process just to get an obvious return value out of it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I'm not sure I understand how it's "self replicating"? An empty file, compiled or not, won't replicate itself. The Makefile to compile the empty c file is also rather large, but even it must be executed in a loop.

Can someone explain the basis of this contest and how this c file is "self- replicating"?

<comment><USER14> I think what they were referring to was a quine

<comment><USER13> yes, but is using an external program (make and cp) really count? I wouldn't consider that really as "self-replicating".

<comment><USER15> every self replicating entry in the competition is compiled with other binaries.

<comment><USER16> And most of biology (including you).

</comment></comment></comment></comment></comment><comment><USER17> There is PDP-11 command (one word, 16 bits) which makes a copy of itself into a previous word (with address, in bytes, less by two) and passes the control to the new copy. Octal 103737... or something like that.

Doesn't require make :) or cp and is pretty active - fills up all the memory space below the starting point in no time.

</comment><comment><USER18> For those not understanding and wanting to see the "source" for this entry... it was a Zero byte file.

<comment><USER6> Download here: [http://www.ioccc.org/1994/smr.c](http://www.ioccc.org/1994/smr.c)

<comment><USER19> Just post the source code here:

<comment><USER20> Done.

</comment></comment></comment></comment><comment><USER21> I hang out on /r/dailyprogrammer sometimes - they had a challenge about these types of programs the other day and called them "quines." Check through some of these if you're interested, a few are 2 characters long (not sure how many bytes that is): [http://www.reddit.com/r/dailyprogrammer/comments/2n11w8/2014...](http://www.reddit.com/r/dailyprogrammer/comments/2n11w8/20141121_challenge_189_hard_write_a_quine/)

<comment><USER11> 2 characters is usually 2 bytes, unless they are using some weird unicode format, in which case it shouldn't be longer than 8 i think.

</comment></comment><comment><USER22> Is the copyright notice supposed to apply to the empty program?

<comment><USER23> Not sure about the copyright, but I wouldn't be surprised if someone patented it in the US.

<comment><USER24> Actually, there was a story about somebody selling 0-byte executable for DOS allowing you to resume programs because of some peculiarity.

<comment><USER25> I'll be darned if I can find the URL to the story, but it is a brilliant application of giving the customer what they wanted.

The short of it is that when you dropped back to the command line, early versions of DOS didn't clear the memory. That meant that the program really just went into stasis, but in practice it meant restarting; see, the program ran off the floppy then, so to save or load to another disk was tricky. Because memory would be executed from the same address, you could insert this disk with an empty executable that would get DOS to send execution to that address, which happens to be the program already in memory.

This had the huge boon of allowing you to drop to the command line, do something, and the resume working! Apparently they sold the disks for like $5 (or pounds) each, and the customers were extremely pleased. And the programmer was got a kick out of having rather impressive return per byte written :)

<comment><USER26> Here you go: [http://peetm.com/blog/?p=55](http://peetm.com/blog/?p=55)

<comment><USER25> I wish I could edit my comment - it wasn't even MS-DOS! But, yep, that is the story. Hopefully I won't forget GO.COM in the future.

Thanks a mil for finding the link! I had a feeling I read the story from HN, and so it was:

[https://news.ycombinator.com/item?id=5920732](https://news.ycombinator.com/item?id=5920732)

</comment></comment></comment></comment></comment></comment><comment><USER27> I once wrote an implementation of the classic Redcode "Imp" program in x86 assembly. It does not satisfy the requirements of this contest, but it does act as the Imp program, perpetually copying itself through RAM. :-)

I just uploaded it to [https://github.com/mct/assembly- toys/tree/master/imp](https://github.com/mct/assembly-toys/tree/master/imp)

</comment><comment><AUTHOR> Related to this article is "Ken Thompson" reflections on Trusting Trust [http://cm.bell-labs.com/who/ken/trust.html](http://cm.bell- labs.com/who/ken/trust.html)

</comment><comment><USER28> lol not quite in the spirit of the challenge.

<comment><USER29> Forcing the creation of a new contest rule is a tradition in the IOCCC.

<comment><USER30> Meh. Empty program doesn't replicate itself. It's similar to recent rule- nitpick discussion about selling for 0$. Selling for 0$ isn't selling and nothing isn't replicating itself.

Definition of replicate is: to repeat or copy (something) exactly

Empty program doesn't copy or repeat anything. Entry rejected.

EDIT: It's not reddit, downvotes doesn't go here for disagreeing. The problem is posed in natural language and it has its own rules. In natural language (at least in English) doing nothing isn't copying or replicating. You may check the dictionaries.

Next time someone will claim claim 1 million sales: million nothings for 0 dollars to nobodies.

EDIT (to other child)

Yes, empty set is subset of other sets but that's because the definition of subset. Copy or replicate in natural language (in which the problem is posed) mean something entirely different.

<comment><USER31> The empty set is a subset of the empty set.

<comment><USER32> Don't forget that the empty set is also the subset of the empty set, making them equal. ;)

</comment></comment></comment></comment></comment><comment><USER33> In redcode

        mov 0,1

is the smallest self-replicating program

</comment><comment><USER34> Really a good joke for "Every TEXT is a quine."

</comment><comment><USER35> Thanks, I was pretty messed up just now after watching the movie Pi, now I'm even worse....

<comment><USER36> In "Pi", the math is from the Dover book by Jahnke and Emde and the formula for the ratio of the sides of the rectangle is wrong.

</comment></comment><comment><USER37> Isn't this a quine, rather than a self-replicating program? A quine produces the source, and a self-replicating program should produce an executable - no? This seems to be a fallacy of equivocation.

<comment><USER38> If you run it, it will replicate itself...

      $ ./smr >smr.out
      $ diff smr smr.out

</comment></comment><comment><USER39>
      smr: smr.c
      	@${RM} -rf smr
      	${CP} smr.c smr
      	${CHMOD} +x smr

this is bullshit if you ask me..

<comment><USER40> Agreed, WTF.</comment></comment>


Should managers know how to code? - <AUTHOR> http://www.scottberkun.com/blog/2010/should-managers-know-how-to-code/ <comment><USER2> I've actually had some experience on both sides of the table.

When I did my first software startup I had no idea how to code, but since I'm pretty good at convincing people, calling bullshit, diplomacy, etc. I managed to get funded and got together a development team. I thought I had a pretty good grasp on what needed to be done, timelines, etc.

Fast forward some years. I've learned to code (Not a genius by any stretch of the imagination, but I know the basics) and I simply cannot comprehend how I could have managed a software company without knowing how to code. There are so many things that seem obvious now that I completely and utterly missed that it's amazing we ever got anything done.

A rewrite of Eric Raymond's famous quote captures it pretty well: _"As a manager, coding is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better manager for the rest of your days, even if you never actually code a lot."_

<comment><USER3> What exactly was it that you learned that made you a better manager? Being able to judge what's easy and what's a lot of work (especially changes)? E.g. some people think that changing all text to a different font size is a lot of work, so they ask you to only change the text size in X Y and Z, which actually is more work...

<comment><USER2> I learned exactly what you're pointing out. Also to better engage in a two-way conversation about the product, which features should be implemented, why we should or shouldn't do something based on technical merits, etc.

I've always had a lot of respect for people that know stuff I don't and if they have good reasons I'll go with their judgement in their area of expertise. But it's a lot easier to engage in a meaningful conversation when you actually know what you're talking about.

</comment></comment></comment><comment><USER4> At my last job (doing .NET Web Dev), I spent the first 2 years under a manager who knew absolutely nothing about programming or really anything technical for that matter. He was, for all intents and purposes, originally hired as a henchman to weed out bad employees because the CEO hated being the bad guy. That made him the COO and as such, the head of IT as well because of how the company was strucuted (or not structured).

The last 2 years saw me working under someone who had been programming for a living for many years. While he was, by his own words, a bit out of his prime and behind the times, the difference between working for the two was night and day. Deadlines became more attainable, requirements became more realisitic and when difficult decisions arose we had someone who could go to bat for the IT department as apposed to someone who always sided with the "sales" portion of the business.

In my mind, anyone directly overseeing a developer should know how to program as well. In small organizations and start-ups, that's not always possible, but if you're somewhat established and you have an IT/IS director, manager, CIO or what have you that can't program a lick .... I think there's an issue there.

</comment><comment><USER5> Yes, they should. Programming languages have these mysterious features called "loops", "conditionals" and "recursion". Without an intimate knowledge of these, you just can't understand _why_ your subordinates do what they do, and you certainly won't have the ability to judge the accuracy of estimates.

Does this mean that managers should be promoted from within the ranks of programmers? Yes, that's exactly correct. Should managers be "non-technical"? Absolutely not. It just doesn't work.

<comment><USER6> "/Absolutely not. It just doesn't work./"

So you're saying then that it has never worked? That's a pretty big assumption.

I am non-technical and I think I fit pretty well with B) in that article. I always said that even if I did not /understand/ programming I certainly appreciated it. That meant I could appreciate how difficult something would be to implement, whereas those non-technical people who did not appreciate programming (my superiors) would ask for something they thought was simple then go ape when it wasn't implemented immediately.

I would spend hours locked away with my programming colleague while I explanied the business logic for what I needed, he would map out that database concepts. Eventually I got a pretty good appreciation for databases.

I'd admit it didn't work perfectly - as a first-timer and more or less accidental project manager I allowed us to over-complicate the project. Were I to do it a second time I would be much better at KISS.

Based on my experience I would have to say it is incorrect to say it "just doesn't work".

<comment><USER7> It depends on how you read "non-technical".

Your personal example is the story of someone who was extremely sensitive to what they _didn't_ know, made very careful allowances for it, and in the end found out that picking up some technical knowledge was pretty much an unavoidable side-effect.

When I read "non-technical", I don't think of a brand new manager who hasn't yet gone through that process. I picture someone who has managed to stay non- technical by _not_ having that acute sense of what they don't know, _not_ making those allowances for it, and as a result, completely avoided the osmosis of technical knowledge.

<comment><USER5> "Non-technical", when said by a manager, usually means something like: "I don't know what you do, I don't want to know what you do, I don't respect what you do, and I'm scared of what you do."

Your "avoided the osmosis" part is essentially correct.

</comment></comment></comment></comment><comment><USER8> If anyone in the Western Canadian area wants to help make "Programming For Managers" a real course, let me know. I don't how much easier my life would be/have been if some of my previous superiors knew what the hell they were talking about (it would have been a lot, I suspect).

<comment><USER9> I'm afraid I'm at the center of the known universe (Toronto), but it you're actually up for a collab, ping me at stan decimal rogers at gmail. I may be a workaday hack at coding (at least by my own reckoning), but I have some teaching and course design in my pocket and an intense hatred of impossible schedules, surprise last-minute spec changes that mean re-architecting everything, et cetera, et cetera (in a Yul Brynner voice).

</comment></comment><comment><USER10> It has been my experience that direct managers of technical people who don't have at least a competent grasp of _both_ technical perspective and business perspective are doomed, almost without exception. This is fairly obvious when you think about it, because these people are a bridge between two worlds, and need to command the respect of both.

The problem is that most managers with only one perspective don't seem to appreciate what they're missing, think they're a good manager anyway, and often receive positive reinforcement of this illusion when the side they do understand (and probably support too much, at the expense of the other side) praises them.</comment>


Early Warning of Human Crowds Based on Query Data from Baidu Map - <AUTHOR> http://arxiv.org/abs/1603.06780 <comment><USER2> hmm, my cofounder has a story of being caught in a stampede like this. Guess I'll forward.</comment>


GitLab – A $1B business where all employees work remotely - <AUTHOR> https://www.forbes.com/sites/alejandrocremades/2019/07/21/he-built-a-1-billion-business-where-all-700-employees-work-remotely/ <comment><USER2> GitLab the company exists because of HN [https://news.ycombinator.com/item?id=4428278](https://news.ycombinator.com/item?id=4428278)

Ask me anything.

<comment><USER3> I was in the team where we decided what to use to serve git repos + to do peer reviews for a big German car manufacturer. We decided on GitLab because it had a normal fork-workflow but was open source and we wanted to divert some of the money into one of the open source projects. Now we have around 600 users in that project.

Most of the things work great but we have the problem that we want to use Jenkins instead of the build in CI/CD solution but the only way to trigger MR jobs from GitLab forks in Jenkins is this non maintained plugin which has been in alpha since we started two years ago [https://github.com/Argelbargel/gitlab-branch-source- plugin](https://github.com/Argelbargel/gitlab-branch-source-plugin)

So I wonder, what is the reason behind not investing into integrations with other CI systems like Jenkins which are hugely popular and used by so many people?

<comment> jl-gitlab Hey there, PM for CI/CD here. Can you point me to an issue in either GitLab or the Jenkins Plugin repo that has more info specifically on what you're looking to do that isn't possible today? Or share specifically what you need here so I can make one? That other project seems to have a few different features and I'm not sure which use cases exactly are important for you.

In any case, we definitely want to make sure you have the right functionalities you need.

<comment><USER3> Basically what we need is functionality which makes it possible to do:

\- there is a canonical git repo for a component

\- a dev doesn't have write access to it

\- they fork it into their own private user name space

\- they change it and create a merge request for the canonical git repo for one of the branches

\- the merge request creates (or triggers) a job in Jenkins => this is where our research showed that only the unmaintained gitlab-branch-source-plugin plugin can do that [https://github.com/Argelbargel/gitlab-branch-source- plugin](https://github.com/Argelbargel/gitlab-branch-source-plugin)

\- Jenkins builds it and reports the status back to GitLab

\- If it created a new job that job is removed after the MR gets merged.

It would be nice if, like the other plugin does it one could have it's own job for this MR with it's own history but I guess we could live also with a shared history if you could have the MR buld history in GitLab only.

 _update:_ I forgot to write that we use Jenkinsfile based pipelines, not sure if this is important.

<comment> jl-gitlab I've created [https://gitlab.com/gitlab-org/gitlab- ce/issues/64995](https://gitlab.com/gitlab-org/gitlab-ce/issues/64995) \- please join us in the conversation there.

</comment></comment></comment></comment></comment><comment><USER4> I just don't get why their support always leaves our company hanging, is this a strategy to success?

We want to renew our license for a lower amount of people as last year and that seems to be a major issue, as we won't get responses from firstname.lastname@example.com and our Technical Account Manager, after giving us directions that simply did not work stopped responding last week.

Friday our license will expire if we don't pony up for nearly twice the amount of seats than we actually need.

The last time I complained here someone bumped up our tickets but we still had to resolve the technical issue ourselves as the only option was to setup the instance differently, which an easy response from a support agent could have told us without a multi week delay.

I love the product, but have stopped recommending GitLab to anyone above a 10 people org for those reasons.

<comment><USER5> Hi @Roritharr - Support Manager here.

It was me who helped your tickets along last time, and I'm sorry to hear that you're having trouble again. Someone should be in touch on your renewals issue soon.

If you're interested in the story; there's a bit of nuance here. Support actually falls under Engineering in GitLab, and licensing falls under Sales. That means that technical issues and upgrades/renewals fall under different teams.

The good news is that we're working hard in both areas to improve. \- We've significantly increased the headcount of the licensing team, this should mean faster responses on licensing queries in the near term future. \- We've formed a Fulfillment team who is hard at work automating away some of the manual process associated with renewals. (You can see their priorities here: [https://about.gitlab.com/direction/fulfillment/#-current- foc...](https://about.gitlab.com/direction/fulfillment/#-current-focus))

Specifically from the Support side, we're discussing process improvements that will mean fewer languishing tickets like you've described. There are a few in flight, but the one I'm personally most excited about is [https://gitlab.com/gitlab-com/support/support-team- meta/issu...](https://gitlab.com/gitlab-com/support/support-team- meta/issues/1771).

You'll note, I did just write it up - so there's not much discussion there yet. If you're feeling up for it, we'd love to have your input. Feel free to leave a comment there if you have any colour that could help.

I hope next time we bump into each other on HN it'll be under happier circumstances.

As always, if you'd like to discuss this more, feel free to email me directly at lyle[at]gitlab[dot]com.

<comment><USER4> Hi, thanks for your response. I'd love to know if our problem is technical or not, as either we're misunderstanding the true-up licensing model or the user limit counting is faulty.

We're coming from a 30 Users License last year, with two true-up on-top of that.

Now we're down to 17 active users, so after our TAMs reply we bought a License with 19 Users. When trying to add the License we're getting an error that in the Last year 30 users have been active so we need to renew for this amount...

Is this a bug?

<comment><USER4> For future reference:

Indeed it was a bug before v12.

GitLab was able to provide me with a License File which worked on our version 11.10.6-ee Installation before our time ran out.

</comment></comment></comment></comment><comment><USER6> The first half of the article doesn't even name the business. The name of the business, GitLab, is hidden in the second half of the article. This is an example of a publication optimizing blindly for Google Search Optimization where they want to improve "Time on site" and other data by keeping the readers on the page as long as possible. It's frustrating. Google's algorithm needs to be updated to make it smarter otherwise publishers are going to write such articles which will cause a loss of productivity of the readers. Not sure whom to blame here, I guess both Forbes and Google share the blame for this.

<comment><USER7> I noticed this when you google "name-of-movie post credit scene". Not a single result will instantly tell you if this movie has a scene after the credits. It will have a multiple paragraph review of the movie and your answer is hidden somewhere in there. All I want is a simple yes or no answer.

<comment><USER8> I found the main discussion threads on the /r/movies surbeddit the easiest way of finding if there's a post credit scene. The info is in the original post, so there's no need to read comments with potential spoilers.

[http://aftercredits.com](http://aftercredits.com) is a pretty good source as well, but I checked it out after your comment and surprisingly it doesn't show in the top search results for "<movie> post credit scene".

<comment><USER9> More and more of my google searches are being appended by "reddit". Someone's asked it before and it takes half a second to load/skip for it. It's sad, but effective

<comment><USER10> Pretty much all of my searches have that operator now. You used to type your keywords and relevant forums would come up on page 1, brimming with information from people who were knowledgable and eager to share what they know. I have no idea what these niche forums are going to be called, so I have to defer to reddit for my searches.

<comment><USER11> The reddit keyword is very useful, and so is just "forum". That keyword tends to pop up on forums, so it's useful for finding those niche forums.

</comment></comment></comment></comment></comment></comment><comment><USER12> "After starting and selling app store Appappeal, Sid turned open-source software GitLab into a fast-growing venture that is on its way to an IPO in 2020.

He took the proceeds from his previous venture, doubled it in bitcoin, and began bootstrapping GitLab.com.

Sid got the first few hundred signups through an article posted on Hacker News. Then together with his cofounder applied and got into Y Combinator. The race to demo day, where they would present in front of top tier investors, was on.

Compressing their three-month plan into just two weeks, the GitLab team had a highly successful demo day, landing Ashton Kutcher as an investor."

<comment><USER13> > Ashton Kutcher

The actor?

Did he start becoming involved in the tech scene after working on the Jobs movie?

<comment><USER14> He's been an investor for quite a while, he even did a few episodes of Shark Tank.

</comment></comment></comment><comment><USER15> Jeez, his surname is spelled differently 3x in the first couple of paragraphs (Sijbrandij / Sijbrandiij / Sijbrandi). Proof-reading, anyone?

<comment><USER16> I suspect this could be an SEO trick for people who mis-spell the name when searching.

<comment><USER17> Ahhh. Finally we understand the genius of "covfefe".

<comment><USER18> Finally, some respect!

</comment></comment></comment></comment><comment><USER19> Wow, had no idea GitLab was close to an IPO. Is there a lesson about saturated markets and differentiation that can be learned from them? I'd be all ears

<comment><USER20> There's probably room for another git* hosted company.

<comment><USER21> There's probably room for lots of them. There's always some unmet need that hasn't been addressed by the market, and everyone needs software these days!

</comment></comment></comment><comment><USER22> I tried switching to Gitlab for my hobby projects over a year ago (before Github had free private repos), but recently, have decided to move back to Github, mostly for UX purposes. Not sure what it is about Gitlab's UI, but I find it more difficult to navigate and parse visually than Github's. I am a hobbbyist developer though and rarely work with other people.

Granted, Gitlab CI was awesome the one time I used it.

</comment><comment><USER23> If you don't know who "he" is, the lead is buried under the fourth sub- heading:

> After starting and selling app store Appappeal, Sid turned open-source > software GitLab into a fast-growing venture that is on its way to an IPO in > 2020.

</comment><comment><USER24> I think remote roles are becoming a lot more accepted in tech. No time wasted on the commute, and companies can save costs of office spaces, etc.

I'm so optimistic about remote working for developers, it's even been a key feature in a job matching platform I've been working on: [https://www.rocketship.dev/](https://www.rocketship.dev/)

<comment><USER25> I think it's also the realization of a supply problem. A lot of companies around the world cannot compete on compensation with the larger tech companies in the Bay Area, and many people don't want to move there, so it's win-win.

</comment></comment><comment><USER26> "What, like it's hard?"

What's hard is not building the business (not harder than building a local business), what's hard is leaving the preconceived notion of how to communicate with people, build trust and collaborate

Until you leave the preconceived notion of productivity = seats in desks and people chattering on the office (roll eyes) then "it is (going to be) hard"

</comment><comment><USER27> Wordpress is another example, they employ close to 1000 remotely working people (as I heard from a friend working at there).

<comment><USER28> Automattic is the name of the company. WordPress is the name of the product.

Anyway, what I like about GitLab and Automattic is they are agnostic-timezone remote company. You can live in any timezone to work in GitLab or Automattic.

Some remote companies only accept certain timezones.

<comment><USER29> What's most interesting to me is remote + scale.

There are many small remote companies that don't try to scale, as they prioritise just having a nice product that solves 1 relatively simple task very well, while having a comfortable life style for the employees.

But so far there's no remote-first company on the stock market.

<comment><USER30> It's only recently become possible to run a remote-first company in an effective and cheap way. Give it time.

<comment><USER29> What do you mean? Video conferencing was already easy to do 10 years ago.

Looking back to the history of GitLab you are right that it just took 8 years to scale the company to this size, but I hope that others are already coming.

<comment><USER30> There are way more requirements to run a company than simply being able to communicate by voice or video. There's a lot of infrastructure and overhead that's involved. Before Stripe, you might have to store credit cards, and then you might need physically colocated servers. Before G Suite and AWS and... I haven't started a startup myself, but I believe there are a lot of variables involved.

These kinds of apps and services, and video conferencing, were all around 10 years ago, but everything's been improved and consolidated enough that now a 100% remote company can actually go toe-to-toe with one that isn't. 10 years isn't that long ago in the scheme of the global market economy. Technological progress takes time. VR was available 10 years ago, but it's still not really "ready for primetime". Remote working solutions, for all aspects of work, are now ready for primetime.

</comment></comment></comment></comment></comment></comment><comment><USER31> We really, really wanted to use and like Gitlab but after a few months trial found the UX very poor in comparison to the main competitor.

The icon heavy interface and general layout decisions made things hard/cumbersone to find, any plans to invest in an improved UX for the web UI?

</comment><comment><USER32> Fyi... A previous comment subtree that includes a comment on Gitlab financials from the CEO/founder: [https://news.ycombinator.com/item?id=18442952](https://news.ycombinator.com/item?id=18442952)

</comment><comment><USER33> >After starting and selling app store Appappeal, Sid turned open-source software GitLab into a fast-growing venture that is on its way to an IPO in 2020.

Open source software?

<comment><USER2> I try to say open core software (some of it is proprietary) and that is what we try to use in our website and blog posts.

Sometimes I mess up and sometimes the journalist prefers a more common term.

</comment></comment><comment><USER34> All they say about the actual 'remote work', is there's a webcam meeting every day.

<comment><USER2> You can find more details on [https://about.gitlab.com/company/culture/all- remote/tips/](https://about.gitlab.com/company/culture/all-remote/tips/)

</comment></comment><comment><USER35> Is it profitable though?

<comment><USER2> Not close to being profitable since we're optimizing for growth (more than doubling year over year). Cash flow positive planned no later then 2023 [https://about.gitlab.com/company/strategy/#sequence](https://about.gitlab.com/company/strategy/#sequence)

<comment><USER36> Can you confirm if GitLab increased revenue 10x in 2018? A previous profile stated the revenue was $10M in 2017 ([https://www.forbes.com/sites/alejandrocremades/2019/07/21/he...](https://www.forbes.com/sites/alejandrocremades/2019/07/21/he- built-a-1-billion-business-where-all-700-employees-work- remotely/#42d13d602aa9)) and this article says it is now $100M. This is a phenomenal achievement, but the valuation ought to be more than $1B at that trajectory.

<comment><USER2> Do did not increase revenue by 10x in 2018. We more than doubled IACV (and hence revenue) in 2018.

<comment> the-dude The what? [https://en.wikipedia.org/wiki/Idle_air_control_actuator](https://en.wikipedia.org/wiki/Idle_air_control_actuator)

<comment><USER37> [https://about.gitlab.com/handbook/sales/#incremental- annual-...](https://about.gitlab.com/handbook/sales/#incremental-annual- contract-value-iacv)

Amazing amount of detail of how Gitlab operates is public.

</comment></comment></comment></comment></comment></comment><comment><USER38> It's an article about GitLab and Sid, since the title doesn't make it clear.

<comment><USER39> Can a mod please update the title?

<comment><USER40> If you feel inclined to, flag the article, but I doubt they will change it as the title of the post is exactly the title of the article.

<comment><USER41> As an answer to your comment, I had flagged the post. Guess what, they changed the title :)

</comment></comment></comment></comment><comment><USER42> Would be interesting to know if they discriminate pay, according to where the person works from.

Edit: Further down the page I saw: "Why they pay based on where team members live". That's petty.

<comment><USER43> There is nothing petty about it. Everyone does it, but GitLab is just more transparent about it. It is up to you whether you accept the compensation level or not, GitLab is far from a monopoly on labour demand

<comment><USER44> Everyone does not do this. I work remote and get a fair market rate (for the value I add, not based on where I live). Unfortunately I couldn't apply to Gitlab last time I was in the market for work because their salaries are both lower in general and lowered even further due to geo adjustment.

I'm fully a fan and believer of remote work, but you need to pay your employees just like any other top tier company would. It's actually even more important as you really want the best people for remote work since they need to be excellent communicators and more self-directed than in-house employees.

<comment><USER18> > I work remote and get a fair market rate (for the value I add, not based on > where I live)

Unfortunately there are two misconceptions here: 1) that companies pay based on added value and not on replacement cost, & 2) that "a fair market rate" does not vary with location, when in reality different locations have different labor markets.

The reason SV companies pay so much is because their candidates expect it, and part of why they expect it is the high cost of living in the area. A company that pays less than average will get worse/fewer candidates, thus a local labor market. For a remote company, paying an SV employee the same rate as a midwest employee is to effectively compensate the latter much higher, and what's fair about that?

<comment><USER44> Companies pay what you can negotiate with them. This is based on value add, and alternatives on both sides of the table. If you can pitch the value you create, you can get paid accordingly.

<comment><USER18> It's very hard to quantify the marginal business value given by a single employee, especially if they're just starting in the position.

Economics is driven by scarcity - supply and demand. Companies have no financial incentive to pay us any more than it would take to hire a replacement. They're in the business of making profit, which necessarily means paying people less than the business value they add, and if a company wants to be very profitable, the only way is to pay substantially less than the value received.

So even if you pitch based on value add, you're really just signaling that you have top skills which are in short supply, and they'd better pay you more or else some other company will. They have no obligation or incentive to pay commensurate with value add, only to pay just enough to keep getting the value add.</comment></comment></comment></comment></comment></comment>


Fatalities vs. False Positives: The Lessons from the Tesla and Uber Crashes - <AUTHOR> https://hackaday.com/2018/06/18/fatalities-vs-false-positives-the-lessons-from-the-tesla-and-uber-crashes/ <comment><USER2> Great points regarding aligning precision/recall of AI systems with actual human supervision capabilities. One quibble: I hate seeing articles uncritically repeat Uber's line that a human driver could not have reacted in the same scenario. The dashboard cam footage they released does not accurately represent either human or car perceptual capabilities [1], and folks recreating the scene have shown that it doesn't even look like a good (or unaltered) example of what a dashcam should have perceived [2].

[1] [https://ideas.4brad.com/it-certainly-looks-bad- uber](https://ideas.4brad.com/it-certainly-looks-bad-uber) [2] [https://dgit.com/residents-recreate-crash-uber-car- case-5616...](https://dgit.com/residents-recreate-crash-uber-car-case-56161/)

<comment> mark-r There's no way of knowing if a human driver could have reacted properly in this specific scenario. However if you live in an area where deer frequently cross the road, you'll know that collisions with deer occur regularly; that would indicate that it's easy to hit things that cross your path, even when you _should_ be able to see them.

<comment><USER3> The human operator was responsible for braking in this situation and failed to do so.

[https://www.ntsb.gov/investigations/AccidentReports/Pages/HW...](https://www.ntsb.gov/investigations/AccidentReports/Pages/HWY18MH010-prelim.aspx)

<comment> mark-r That was my point, human operators are responsible for not hitting deer yet it happens every day. The only reason it doesn't happen to people more often is that people are better at avoiding running in front of cars.

<comment><USER4> >That was my point, human operators are responsible for not hitting deer

How is this even comparable?

A deer jumping in front of a car is not the same as a person walking the bicycle slowly across several lanes (and almost making it to the other side) on a rather well-lit road.

<comment><USER5> Because the human is currently monitoring the car to not hit a deer, as other comments mentions, it can take dozens of seconds to regain full awareness.

<comment><USER3> Dozens of seconds? Have you ever even driven a car? lol

<comment><USER5> Yes, dozens of seconds. This is the scenario of "human was actually doing something entirely different because the car is self driving"

This is _NOT_ classical reaction time.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> This set of trade-offs in self driving cars is exactly the same one that CAD (computer aided detection/diagnosis) systems have been making in medicine for decades. In many cases both type I and type II errors will (with statistical certainty) kill people over enough iterations.

It's not an easy problem, but the best you can do is demonstrate that the system improves on the standard of care. In other words, overall the trade-off has better outcomes than not using the system. The same will be true for self driving cars if/when they reach mainstream use. The important thing is the average performance is improved significantly.

It's worth noting that, like the CAD systems, focusing too much on fixing an individual error can cause a degradation to the overall system. As these things get better and better, you'll have to be much more careful about applying non-obvious fixes, or risk a much worse outcome that doing nothing at all.

<comment><USER7> Imagine a CAD system that was so fundamentally unreliable that it ignored positive hits because the high rate of false positives otherwise would make the system useless. Instead, the CAD system came with a warning printed on the instruction manual that a doctor had to review every scan anyway.

<comment><USER8> Welcome to breast cancer screening.

The current systems are so good at detecting tiny anomalies that probably don't matter that their usage has had to be tuned down.

<comment><USER6> You have to be very careful with false positive rates with something like breast screening, as the work up rate has definite negative consequences. Radiologists have too high a false negative rate on such screens, so you're trying to achieve a balance. To be really blunt about it, you are trading off complications/deaths from missed cancers against complications/deaths from biopsies, but these categories occur at very different rates.

</comment></comment></comment></comment><comment><USER9> We're asking a lot from this kind of software (for good reasons), but humans commit hundreds of leaps of faith of various severity on the roads daily -- failure to yield, failure to maintain a safe following distance, assuming other drivers immediately adjacent to you, like in lanes that are significantly slower than yours, will keep driving safely and carefully. Urban, peak-hour traffic on most US freeways is an exercise in collective insanity, riding people's bumpers at 55+ mph (and often significantly higher), leaving little room to stop for incidents [1][2][3][4] or debris.

But only a small subset of these situations result in significant accidents, because unimpaired humans, largely, have some intuition for self-preservation. On the other hand, we're expecting an algorithm coded by humans to perform better than a complicated bioelectric system we barely understand.

Waymo's self-driving program has opted to thoroughly understanding its environment, which is why their cars drive in a manner that bears no resemblance to how humans actually drive. We as a society have to eventually reconcile the implications of the disconnect.

[1] Unsafe lane change in traffic with different lane speeds: [https://gfycat.com/CleanGleefulArawana](https://gfycat.com/CleanGleefulArawana)

[2] Tailgating causes crash, swerve, multi-vehicle accident: [https://www.youtube.com/watch?v=j0rj2sZ1KA4](https://www.youtube.com/watch?v=j0rj2sZ1KA4)

[3] Inattention to incident causes further accidents: [https://www.youtube.com/watch?v=hZL6OKwQGew](https://www.youtube.com/watch?v=hZL6OKwQGew)

[4] Inattention in slowing traffic causes accident: [https://www.youtube.com/watch?v=Ff7wbSwTuEk](https://www.youtube.com/watch?v=Ff7wbSwTuEk)

<comment><USER10> human drivers routinely do things that are not justifiable by vehicle physics (e.g. stopping distances) because they have a comparatively sophisticated and unconscious understanding of our physical world, how changes may develop and how other human drivers or pedestrians might react. self-driving is a much harder and unlikely problem than the perpetual hype-cycle is willing to admit.

<comment><USER11> Mostly because they use the heuristic of "see, nothing happened last time" and do it again but with a little less safety margin.

<comment><USER12> It's partly that, but also a matter of human drivers trusting each other to some extent. In congested areas if you leave the recommended safe stopping distance then another driver will always cut in front of you. So people adapt by closing up the gaps and hoping the drive in front doesn't do anything stupid.

<comment><USER13> I find this one interesting. I rarely drive in the city, so when I do the distance in queues seems pretty crazy. But at some point I stopped caring that people cut in in front. The active cruise control keeps my distance now (apart from when we're stopped) and often people will use that gap. But... so what? Let them and keep your distance again. It really improves the experience.

<comment><USER11> If you try to account for it, it's not much time at all. And you're improving traffic flow by providing a means to change lanes (a bit more) safely. Most people "cutting in front" are actually just in search for a spot.

</comment></comment></comment></comment></comment></comment><comment><USER14> _If a company is playing fast and loose with the false negatives rate, drivers and pedestrians will die needlessly, but if they are too strict the car will be undriveable and erratic. Both Tesla and Uber, when faced with this difficult tradeoff, punted: they require a person to watch out for the false negatives, taking the burden off of the machine._

Companies should not be allowed to punt this way, when lives are on the line. This really is a problem in need of a regulatory or legislative solution, as multiple companies prove they don't have anyone's interests at heart, but their own. Worse, every pedestrian, cyclist, and other driver on the road who didn't sign up for this in-the-wild alpha is being drafted to enrich the likes of Tesla and Uber.

<comment><USER15> Lives on the line? On average, existing cars kill more than 100 people each day on American roads. The current system of human-driving cars has killed one million Americans over the past couple of generations, mostly from human error. To save lives we need to push forward on self-driving tech.

<comment><USER16> No, on average existing _drivers_ kill more than 100 people each day [source?].

There's no proof yet that self driving cars are safer than human drivers. And more importantly there's a big difference between being safer on average than a human driver, and being safer than the average human driver.

<comment><USER17> The average was 102 per day in 2016, and that is just in the U.S. [https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...](https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in_U.S._by_year)

</comment></comment></comment></comment><comment><USER18> I can still see the people commenting that the Tesla driver did not had his hands on the wheel and he was warned when this warring happened 15 minutes before the accident, so the Tesla PR blog blaming the driver had results proving again how hard it is to undo a lie/almost lie.

<comment><USER19> Also, the people still commenting that the Uber video is meaningful. That's not from the vehicle sensors. That's from a completely separate dashcam and recorder.

</comment></comment><comment><USER20> A video was released today showing what the classifier in Tesla's Autopilot sees, provided by an individual who hacked it. False positives galore:

[https://youtu.be/Yyak-U2vPxM](https://youtu.be/Yyak-U2vPxM)

<comment><USER21> Dunno about 'galore'. The color of the circles seems to correlate with the confidence.

<comment><USER22> It's stationary (orange) vs. moving (green). Tesla ignores stationary objects detected by radar and the video makes it painfully obvious why.

</comment></comment></comment><comment><USER23> > In contrast to the Tesla accident, where the human driver could have saved > himself from the car's blindness, the Uber car probably could have braked in > time to prevent the accident entirely where a human driver couldn't have.

That's a strong statement. Watching the actual video [1] of the Uber accident, it seems both an attentive driver (she seems to be not looking at the road before the crash) or a better decision algorithm, could have prevented the crash. Keep also in mind, videos are very bad at viewing low light shots, and the scene must have been significantly clearer to both the driver and the computer when you're actually there.

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

<comment><USER24> Why would it be clearer to a compuer? Unless thhe car has some extra sensors (radar, laser), surely it cannot see better than the camera?

<comment><USER25> Uber's self driving cars have both LIDAR and Radar in addition to cameras.

[https://www.gearbrain.com/autonomous-uber-car- technology-255...](https://www.gearbrain.com/autonomous-uber-car- technology-2551793303.html)

</comment></comment></comment><comment><USER26> Turning one system off in favor of another is basically admitting that they have no faith in their software. Also isn't driving a car with sensors (without self-driving tech) basically a giant data collector? The mere act of driving a car (with a human brain) should help a SDV system understand a false-positive and a false negative simply by learning what a human does in contrast to what the machine thinks it is supposed to do.

I imagine this is what separates Waymo and the others. I feel like Waymo is using math/neural nets, etc.. whereas Tesla and Uber were probably giant hand- written if/else machines. I have nothing to back that up, except that that's _kinda_ what this article is about.

<comment><USER27> Speaking for Tesla and Uber, they use neural nets. Tesla has the most data which is what you're referring to above and they do exactly what you were stating. The software is/has always been shadowing human drivers, that is learning and comparing to the decisions it would make on its own. Uber is also most definitely using a similar set up. I think neural nets are a basic necessity in this field since there are an almost infinite number of scenarios.

</comment></comment><comment><USER28> It seems like self-driving cars may not (and maybe should not) become commonplace until the roads are built for self-driving cars – that might be a better thing to focus on, instead of systems that mimic human judgment.

<comment><USER29> Seems unlikely that road infrastructure will be upgraded/changed prior to construction of self driving cars.

When developing the self driving tech, a company retains all IP associated with research/development costs. Would they ever instead pay for development of public infra? Would a municipality build roads that conform to Company A's standard of self driving roads, omitting the requests of Company B?

<comment><USER4> >Seems unlikely that road infrastructure will be upgraded/changed prior to construction of self driving cars.

By that logic, railways would have never been built.

"Why would I invest in constructing a special road for that engine of yours? Make it go on dirt roads as well as a horse does, then we'll talk"

<comment><USER30> Horse and cart never worked all that well, to the point that long distance travel by land was extremely rare. Deep ruts would form in the dirt roadways and mud would cause constant obstruction. It was easier sail around South America than to travel by land between San Francisco and New York City.

It wasn't until the railroad that travel by land was possible at scale. For the USA and Canada the railroad was seen as the only way to keep the vast land together as a single nation which is largely why it was subsidized. Further much of the subdisdy was land grants to land which would otherwise be economically useless without the railroad to allow transport of goods.

While self driving vehicles may improve efficiency of our roadways it is unlikely to be anywhere near the same scale of improvement that railroads brought, and the need to connect the country for political reasons is not there.

</comment></comment></comment></comment><comment><USER31> I think this is one of the first time in my life i see marketing (calling something « autopilot » which it is not) and overhype (we have to be the first to have self driving cars, now !) actually kill people and not just rip people or investor off.

I think history will judge those companies very severely, and i'm wondering if justice isn't going to be just as severe right now.

<comment><USER32> Cigarettes were advertised as good for your health, for decades.

</comment></comment><comment><USER33> This certainly explains reports of almost every Google car accident being the case of human rear-ending it. Google did it right from the start, didnt gamble with false positives.

</comment><comment><USER34> I will hold to my opinion stated before, these systems are not safe enough to be on public roads as of yet let alone in the hands of consumers.

that out I still see no reason why we don't adapt limited access roadways to support self driving in that realm. a large number of cities have dedicate HOV and (express) toll lanes that can all be adopted and marked much easier to support self driving capability in a controlled environment. plus its probably a good chance than both manufacturers of cars as well as AD systems along with drivers themselves would be willing to pay more for such access. I just recall the imagery from the old William Shatner series Tekwar that showed a similar approach, get on highway and car takes you into the city. It could even then be extended to service event centers so that it continue driving for you till parked; think off expressway to airports and stadiums

</comment><comment><USER35> I wrote about this recently as well. This is actually going to be more of a concern as we incorporate models into everyday products. Stakeholders and QA need a solid understanding of Type I and Type II error so they can assess how much risk they're willing to take on and make that part of the quality process.

Shameless plug: [https://blog.d8a.me/the-qa-of-stochastic- processes-a15a94065...](https://blog.d8a.me/the-qa-of-stochastic- processes-a15a9406519c)

</comment><comment><USER36> Nice article; thanks.

* * *

. Tesla claims: A 40% crash rate reduction with the autopilot as compared to no autopilot, over an 18 month period [1].

. If this is true—and we could imagine it is (at least partially?)—then Elon's remark to journalists would make sense:

"It's [..] irresponsible [..] to write an article that [..] lead people to believe that autonomy is less safe," [..] "Because people might actually turn it off, and then die" [1]

* * *

But to have an opinion about the autopilot's risk statistics I would also need to know: a) What populations (data) they compare; b) How each population is defined (inclusion and exclusion criteria); c) What's the sample size (18 months, and?); d) Who makes these calculations (to clearly identify possible conflicts of interests).

\- Not sure if this type of data is publicly available?

* * *

Actually the National Highway Traffic Safety Administration (NHTSA) seems to indicate[1]: 1) that the data comes from Tesla—cf. point d) => conflict of interest; 2) Autopilot on/off was NOT used for the risk statistics—although it's central (point a); 3) instead the "40%" would measure the "number of airbag deployments per million miles" which is a proxy-metric that's not directly related to car accidents.

\- Hey, this is odd (it's definitively not a Science or Nature method protocol).

* * *

. "The Insurance Institute for Highway Safety suggests: A "13%" reduction in collision claim frequency, indicating sedans with Autopilot enabled got into fewer crashes that resulted in collision claims to insurers."

However it's a small difference and there're possible confounders like social status (a "Tesla driver"), gender, geographical area, and usually the confounders have a large influence on experiments, so it's unlikely that this (small) 13% difference would remain if we adjust for confounders...

* * *

Here's the article AARIAN MARSHALL on Wired. [1] [https://www.wired.com/story/tesla-autopilot-safety- statistic...](https://www.wired.com/story/tesla-autopilot-safety-statistics/)

</comment><comment><USER37> Could any of the fatalities be related to the malicious code commits? [1]

[1] - [https://www.fastcompany.com/40586864/read-elon-musks- email-a...](https://www.fastcompany.com/40586864/read-elon-musks-email- alleging-there-is-a-saboteur-at-tesla)

</comment><comment><USER38> >It may seem cold to couch such life-and-death decisions in terms of pure statistics, but the fact is that there is an unavoidable design tradeoff between...

The fact that we as a society can't have an adult discussion about that topic is a large part of why it's so hard to strike the right balance.

</comment><comment><USER39> Good thing L5 self-driving can be done without low-latency LIDAR and that Tesla didn't defraud many Model S owners by selling them cars fundamentally incapable of providing L5 self-driving.

/s

</comment><comment><USER29> The upside of self driving vehicles is so immense that I can't help but find in favor of giving leeway to companies developing this tech. I would vote legislation limiting the accident liability of 'qualified' companies developing self driving tech. No, I don't know what separates 'qualified' from 'not qualified'.

Try looking at this a different way: there were 37,461 vehicle related fatalities in 2016 in the US alone. In the current risk-averse climate, would we - over the early 1900's - ever allowed the development of public infrastructure to support an invention leading to so many fatalities? Likely not, but the benefit we enjoy from motorized transportation far outweighs the cost of those 37k yearly lives. The point is that continuing with a risk- averse, liability-obsessed development culture will stifle invention that can otherwise lead to great quality of life improvements.

<comment><USER14> Then you and other people like you can volunteer to work at a test track as obstacles. Leave the rest of us out of it. You're entitled to your utopian fantasy of what _might_ be, and the best way to express that is to put your life on the line instead of volunteering others to do it.

 _Statements like this seem to be trying to make the point that any amount of increased public risk is unacceptable unless everyone opts in to accept it._

No, statements like mine reject the notion that sacrificing lives today for the possibility of an unproven improvement sat some unspecified later date is morally reprehensible. My answer is to invite the person endorsing this to put their own life on the line instead. If we were talking about medical testing on humans instead of cars, maybe it would be easier for some to understand. "It's so bad today, the only course of action is to act recklessly to improve things as fast as possible!" is a thoroughly rejected argument.

<comment><USER40> Statements like this seem to be trying to make the point that any amount of increased public risk is unacceptable unless everyone opts in to accept it.

I find this argument entirely uncompelling. There are an inordinate amount of risks imposed upon me while operating in society which I neither agreed to nor would I given the choice, aside from in a hand-wavy "social contract" sense.

However as a member of society I am in fact compelled to accept myriad risks on a daily basis imposed on me for the benefit of others, or the benefit of potential scientific advancement.

This concept that a society cannot morally make risk-reward decisions in the course of technological advancement is entire bunk IMO. Government can absolutely morally make these trade offs and does so _constantly_.

I feel pretty good about the current legal and regulatory frameworks and the technical chops of the NTSB to monitor developments in self-driving R&D adequately.

One thing I am certain of is that we _absolutely must_ succeed in developing, productizing, deploying, and ultimately mandating self-driving technology. Millions of lives and trillions of dollars are at stake, and yes, society as a whole will incur individual loss of life in the pursuit of this goal. An attempt to develop the technology with zero risk of collateral damage would in fact cost many more lives overall.

<comment><USER41> So far, per mile driven, the fatality rates of Uber and Tesla SDVs are far higher than human drivers in statistically safer than average vehicles.

Waymo has a better track record but essentially refuses to drive at significant speed -- I have yet to see a Waymo SDV place itself in a situation with a higher speed limit than 35mph, and I see them a lot.

<comment><USER42> I regularly see the Waymo vehicles in 45 mph zones on my commute. I can't say I've seen them go any faster, but I spend about 95% of my time on roads marked 45 mph or less.</comment></comment></comment></comment></comment>


Ask HN: How to impove in CI/CD - <AUTHOR> CI/CD concepts are crucial parts of each not-so-small software project. Proper automation and consideration of probable issues support team through the whole journey.
I've seen companies ignoring it or doing it wrong in their concrete case.
I want to improve in this domain because DevOps quality is correlated with a company's success (defines processes in so many ways).
What is the best way to acquire practical knowledge in CI, CD and DevOps? The historical perspective could also be super interesting!
Thanks <comment><USER2> It is all broken. DevOps mean that developers will fix infra issues without enough access/permissions/skill. CI means that developers will ship broken code to production because test coverage is in form of reverse piramide. CD means the PO will organize demo on half-finished features. Whole DevOps culture encourages using experimental tools that are not production ready.

My advice. As a developer focus on tests. As Ops focus of simple and process. As manager avoid Cloud Evangelists.

</comment><comment><USER3> You know how rat problem in the city cannot be directly solved by going after rats because rats are emblematic of all other problems in the city. CI/CD is the equivalent of that.

</comment><comment><USER4> I can recommend the following books: Accelerate: The Science Behind DevOps Book by Gene Kim, Jez Humble, and Nicole Forsgren

The Phoenix Project Novel by Gene Kim, George Spafford, and Kevin Behr</comment>


Four Zero Days Disclosed in Internet Explorer - <AUTHOR> https://threatpost.com/four-zero-days-disclosed-in-internet-explorer/113911

<comment><USER2> Not a very informative article. Nothing in either the article or the linked "advisory" mention which version(s) of IE and which versions of Windows are affected.</comment>


Startup School Wiki - Wiki inc videos of startup school 2006 and 2005 - <AUTHOR> http://startupschool.infogami.com/ <comment><USER2> Ooo good PG video. Will be bookmarking this one...</comment>


Why silent [browser] updates boost security - <AUTHOR> http://www.techzoom.net/publications/silent-updates/index.en

<comment><USER2> It depends on the update . . .

I'm currently hosting a series of meetings where we are certifying all of our existing IE 6 and IE 7 based applications for IE 8. Much is broken because of hacks necessary to make these sites work properly in older versions of the browser.

While I'll be the first to say that we apply the IE Cumulative Updates the day after release ... silently ... to every PC in our company, we wouldn't dream of deploying a major browser update without reviewing it. Anymore, 99% most of our applications are browser based. A major browser update (Firefox 2.0 -> 3.0 or IE x.0 to IE x+1.0) can be as impacting as upgrading the operating system silently.

Yes, yes, I know. We standardized on IE, bad us. It wasn't my call :o).

</comment><comment><USER3> As a practitioner, I find this hard to argue with and somewhat obvious, since the preceding 10 years have largely been about how hard it is to get critical patches adopted in opt-in schemes.

</comment><comment><USER4> The results are kind of bogus in a lot of cases, though. For Safari, for instance, there are multiple "correct" versions (one for 10.5 users, another for 10.4 users), so uptake of a new version can't be expected to ever reach 100%. Same goes for Firefox, where some users are still using the 2.x branch: they obviously won't get a 3.x update.

Really, Chrome is at an advantage here by only having a single version. Comparing other browsers' update cycles to it is hardly fair.

</comment><comment><USER5> The title is a little off: security updates boost security, and silent updates boost adoption of updates.

The recent stink with Adblock Plus and NoScript using my browser in their personal snowball fight makes me leery of auto-updates. Making the normative choice the default setting has an okay track record, but I'd like as many as eyes as possible helping me keep developers in line with my needs.

</comment><comment><USER6> As a user, I find this pretty easy to argue with, since the preceding 10 years have largely been about how software companies can't be trusted with silent update capability.

<comment><USER3> This is a really weak argument, since vendors can undertake the same illicit actions you're averring using opt-in updates. Updates that aren't what they say they are remain a problem regardless of opt-in/opt-out.

<comment><USER6> Except that the opt-in process enables transparent third party verification. Updates can be tested individually. When an opt-in update misbehaves, word can (and does) spread. It can be avoided.

If a silent update misbehaves, how do we have a chance to -do- anything? The update was likely applied before we could even open an app to get the news. Should we go online in a VM to verify that it's safe to connect with our preferred OS/software?

<comment><USER3> The argument is for transparent opt-in updates. It's not for eliminating opt- out. I agree that there should be an opt-out.

The argument about third-party verification is a red herring. I feel somewhat qualified to argue that third parties will "verify" updates no matter how they're disseminated; reversing patches is a bread-and-butter part of security product development.</comment></comment></comment></comment>


Analyzing haveibeenpwned password safety with kNN - <AUTHOR> https://medium.com/@eugenhotaj/knn-for-pwned-passwords-e4895f66b836 <comment><USER2> This doesn't actually analyze HIBP in any way. In this case, HIBP is just an inspiration for this article.

This algorithm just checks a password you enter against the Levenshtein distance of words in the password database, and if you are close enough, it tells you that there is a match.

That's two totally different things.

And the HIBP database is huge compared to anything the author might have dealt with here.

Moreover, algorithmic complexity of calculating Levenshtein distances on huge databases has not been considered.

<comment><USER3> Hi, author here. Thanks for reading! Yea these are all great points and most are brought up in the article.</comment></comment>


How to make license keys? - <AUTHOR> What is the best way to make license keys for an application? (C ++) <comment><USER2> Maybe you should look for a DRM system?

</comment><comment><USER3> A license key is just a string you can easily track, and depending on delivery of the key you might want to make it easy to type.

If it's all downloadable/copy-paste, just use any GUID generator.

If you're relying on people to type it in, I'd go with alpha-numeric, cleaning up ambiguous characters (Such as 1/l/I) and keeping the length moderately short, no more than 6-8 characters split up into two sections with a space in between.

It's better to limit tries than make a crazy long key that no one can type.

That's based on you asking how to "make" license keys.

If you're also asking for help how to verify them offline for example, it's a different story.

<comment><AUTHOR> Thank. I think I need to ask how to verify these keys?

<comment><USER3> There are different ways to do it depending on if the client is online or if it has to be offline, and using a dongle or not (Uncommon today).

If the client will be online you can just do an API call and check on start, if there's no key show a splash screen with the option of entering a key.

If there IS a key, send it (securely) to the API and do something depending on the result.

Here's a good article for how you could do it for offline keys: [https://www.brandonstaggs.com/2007/07/26/implementing-a- part...](https://www.brandonstaggs.com/2007/07/26/implementing-a-partial- serial-number-verification-system-in-delphi/)

It's written for Delphi/Object Pascal but the principles can be implemented in any language.

<comment><AUTHOR> Thanks for the link. I think this is what I need.

<comment><USER2> You should write your own algorithm for creating the KeyGen. Also, think about how the key will be checked. The key can be tied to the MAC address of the computer. But this way has some pros and cons.

<comment><AUTHOR> Thanks for the tip. I found several ways to generate keys. But I don't know how to organize the process of checking and locking the keys when they are transferred to third parties.

<comment><USER2> Maybe you should try a ready-made licensing system? Try ready-made DRM-systems (Digital rights management). You can find a lot of information on Wikipedia. There are examples of free and paid programs. Also, you can use a ready-to-use key-making tool. ArmDot for example. As usual, such programs are paid. But maybe you can find something free on the GitHub. Good luck!

<comment><AUTHOR> Thanks for the tip. I will study this question in more detail.</comment></comment></comment></comment></comment></comment></comment></comment>


What If API Status Pages Were Standardized? - <AUTHOR> http://redotheweb.com/2012/12/11/head-up-what-if-api-status-pages-were-standardized.html

<comment><USER2> This is a very appealing concept. It would make the CircuitBreaker pattern a lot simpler to implement: [http://martinfowler.com/bliki/CircuitBreaker.html](http://martinfowler.com/bliki/CircuitBreaker.html)</comment>


Heat Transfer in the Modern Kitchen (lecture by Nathan Myhrvold) [video] - <AUTHOR> http://www.youtube.com/watch?v=fGKSdQJrIWY

<comment><USER2> Will he sue me for royalties if I watch this video?</comment>


Return of the Statically Typed Languages - <AUTHOR> http://beust.com/weblog/archives/000483.html

<comment><USER2> I didn't much agree with this guy's post, but here's where he _really_ lost me:

"Javascript is on the verge of becoming part of the assembly language family, and toolkits like GWT are making sure that this will happen before too many developers join the pool of low level language victims. I'm sure you can relate to that stigma."

In the first place, JS is a neat little language that, with a few (okay, a lot) more libraries could easily serve as a replacement for Perl, Python, Ruby, etc. Categorizing it as 'low level' or 'assembly' -like seems like a terrific mistake.

In the second place, the assumption that someone would rather work with Java/GWT than JS seems a little provincial. His point seems to be that _he_ would rather code Java than JS, GWT makes that possible so .... everyone will use the tools he prefers. I think there's a flaw in there, somewhere.

In the third place, what 'stigma' is associated with the 'assembly language family', and/or what makes someone a 'victim' of a 'low level' language? Everything has its place, and while it's only rarely useful, a background in ASM is an excellent foundation for a programmer's knowledge. ASM is also useful for solving the occasional nasty bug, understanding security vulnerabilities, working with bytecode, and reverse engineering for fun and profit.

The third point may be minor, but it really poisons the whole article, for me.

</comment><comment><USER3> Strangely, just yesterday, I got this email in my junk account:

Subject: My name is Cedric Beust and I caused you to get unwanted email

Message:

Hello,

I am Cedric and I blog on beust.com.

I have allowed everyone's email to be exposed throught my sloppy, weak security. I work at Google and this secruity lapse reflects poorly on Google too of course.

If you received this email, then your private email address has been scrapped from my weblog and posted to <http://www.newsreadersite.eu/?page=562>

This error on my part cannot be undonw of course. The mailbots have already scrapped your email address and now your address is runined forever. I hope it wasn't important to you.

I like to talk about important things like computer languages and architecture on my weblog, but I know so little about security that I allowed all of your addresses to be scrapped.

Sorry I am so lame,

Cedric

<comment><USER4> I got the same email. And I found out it was true. I googled the email address to which it had been sent and in fact, it was online at <http://www.newsreadersite.eu/?page=562>

Which goes a long way towards explaining why I have started getting SPAM on a previously clean email address.

The original author is correct, if you are a system architect at BEA and then you move to Google and you still can't keep a blog site secure, it is pretty lame.

</comment></comment><comment><USER5> If I'm going to read an opiniated piece, it might as well be insightful.

<comment><USER6> Yeah, this guy is clueless. I could do a point-by-point on how he's wrong, but I don't have time to nitpick everything. What about this: _Emacs users need to evolve?_ To what?

There is nothing else like emacs. Sure emacs lisp could use some help (some of us are working on adding coroutines for parallelism), but that doesn't mean it's dead. If anything else were like emacs but better, we would all ditch it.

Summary: this guy is fucking clueless. He's an IDE-wielding weenie that has only ever used Java. Great.

</comment></comment><comment><USER7> Method name renaming was licked in Smalltalk, even in things like specs (which predated XML, but served much the same purpose.) So long as everything's an object in the image, you're fine. (Excepting goofy things like constructing message sends at runtime.)

Things like properties files and pickled objects that left the image -- you aren't covered then. But there's little you need those for that you can't do in-image.

</comment><comment><USER8> Some of those observations were interesting, but I'm not sure how they fit together, and I didn't come away with a clear understanding of the author's arguments for statically typed languages...

<comment><USER6> His argument boils down to "I like Java, and saying that it's only around for political reasons is wrong. After all, I like it! Yeah, it's true I've never bothered learning much about anything else, but still... my opinion is somehow relevant because I have a blog."</comment></comment>