skysight-inc/HackerNews huggingface dataset:
I don't like semver.

If the library follows the rules, then...

Separation of minor and patch versions doesn't make sense. Both in the case of a minor or patch version change the client should be able to upgrade to the latest version.

A major version change means that backwards compatibility is likely broken. In that case, we're actually talking about a new library.

Therefore you can just use a single integer as the version number, and if you break backwards compatibility, then you change the library name. If you had a library called MyLib with version 1.0.0, then you can just go with version 1 instead. In case of a patch (no functional change), you go to version 2, and all clients can immediately upgrade. Then if you add a new feature, but backwards compatibility is preserved, you can go with version 3, and all clients can immediately upgrade. If you break backwards compatibility, then you rename your library to MyLib2, so it's clear to everyone that this is a new library (with similar functionality).

The real reason for minor and patch versions is that libraries actually don't follow semver, and patch version change means 'small change, don't worry about re-testing', minor version change means 'not that small change, you should re-test' and major version change means 'we've very likely broken most dependencies'.

In real life, you need to re-test anyway.
The article addresses this. He did a poll, and just under 50% of people use the default ports. So just by changing your default port, you eliminate half the break-in attempts.

Now you're absolutely right that this only deters less-skilled/inept hackers, a more competent hacker easily gets past this. But it's worth dwelling on the fact that we still stopped a substantial number of requests. Port knocking is definitely an improvement (i.e. more obscure). I'd guess with port-knocking more than 90% (even 99%) of attempts would completely miss it. The goal here isn't to rely completely on obscurity. It's security in depth. Your SSH server should still be secure and locked down.

The other question with this is what's your threat vector. Most people decry security through obscurity because an APT can easily bypass it. They can, but most people trying to hack you are script kiddies. Imagine an SSH exploit was leaked in the wild – all the script kiddies would be hammering everything on port 22 immediately.
Right.

They don't just "encourage" developers to consider error paths, they "force" them to do so.

The concept of checked exceptions is very sound, as is the more general concept of compiler enforced error checking. Very, very few languages have that (only Java and Kotlin in the mainstream league).

Languages with a solid implementation of algebraic data types offer a good first step in that direction but they still require users to manually bubble and compose monadic values, which introduces an unnecessary, and sometimes intractable, level of obfuscation and boiler plate.

All other languages provide weaker approaches to this concept that are library enforced, not language enforced, and therefore more prone to being overlooked since they require discipline from the developer.
I'm just saying that port knocking just results in another secret you have to manage. It's just adding another locked door. Why use a locked door that's a pain in the ass and insecure in transit?

If you want two layers of secret-based auth- why would you make your second layer one that's objectively less secure and more unwieldy than other layers?
I think it applies to individual and team movement too?
I run a cyber software company with a product basically structured on this principle (deception.)

The swiss cheese picture is excellent, since that is how stuff happens in the network internals, with lateral movement and other internal activities.

Say an adversary has to jump 5-10 hops from initial point to target system and you can, with very lightweight obfuscation and ”obscurification”, increase the attackers mistake rate dramatically - it makes a ton of sense from a risk and economic perspective.

Consider the alternative (succesful internal hardening and monitoring) which is way out of scope resourcewise for most.
Uber (and any other "real-world" service) does not (and I believe are not even allowed to) use in-app purchases. This rule only applies to "virtually-provided" services.
WhatsApp Plus APK Download
C# has inner (local) functions which are close in semantics to lambdas but have names. I didn’t think I’d use them at first, but actually I use them all the time and often prefer them to raw lambdas.
1) I’m talking about the convenience of purchasing (and easily accessing past purchases) of app stores, not logging in to each app individually. Many apps don’t even offer that.

2) The main things that come to mind are the same advantages of native apps vs web apps. Integration/access to native API features, CPU/GPU performance, etc. Web browsers can support these things but don’t always.

3) Those specific categories aren’t possible on iOS because Apple prohibits them! That is exactly why Stadia/xCloud isn’t available.

4) Discoverability is hard with tons of apps but it's probably not impossible to do better. There’s not a huge incentive for Google/Apple to fix this since they charge to advertise in the store, some other stores don’t do this.

5) I was thinking about console games here, Switch games are often pretty different from in app purchase based mobile ones.

I think the difference with engines etc is there are big network effects - people buy phones based on the ecosystem which is determined by existing market share. IMO this is why Windows Phone died and it’s not just a matter of enough money or technology.
How I Code (with a little help from +20k markdown notes)
As a developer, I'm often shocked at the relative few numbers of tech workers that practice any sort of consistent note taking. When I find people that do, it is usually as one giant README or through keeping a paper journal.

I think a large part of the issue is that the field changes so fast and things become out dated so quickly. Taking notes seem like a Sisyphean task where trying to keep up to date is about all you can do.

Note taking can serve many purposes, for myself, notes serve as a cache (think redis, but for your brain). If I've spent more than 5 minutes debugging an issue, I never want to spend 5 minutes of my life re-solving the same issue.

The problem is the sheer number of issues that you might encounter on any given day and trying to come up with a system that is easy to write, quick to read, and will scale with the number of notes you put in it.

Over the last decade, I've developed what I call a hierarchy first approach to note taking workflow that has led me to accumulate +20k markdown notes, all of which I can reference in a few seconds. I refer to these notes every few minutes. I owe a lot of my relative "success" in my field, as well as in life, to the knowledge inside these notes.

I recently did a writeup of this workflow and wanted to share it in case it inspires others :)

https://www.kevinslin.com/notes/3dd58f62-fee5-4f93-b9f1-b0f0f59a9b64.html
The attacker who had already compromised the integrity of the system in question has to guess or probe for a random number with relatively low entropy in order to do something useful and straightforward with that already compromised system.
> Just wait until you learn what % retail used to charge developers for promoting, distributing, and selling software.

Zero %.

Retail used to buy boxed software and sell it at risk. Were Apple buying units of software/service up front and the taking a risk reselling it, it would be valid to compare the split of end-user cost with classic retail, but Apple's not doing that, so it isn't.
I don't know if you can really have the perspective on this if you were a classically trained musician. You already knew all that stuff inside and out.

I think a lot of music produced on a qwerty keyboard eschews huge amount of music theory just because it's produced that way.

My perspective was from the other way.. trying to learn it all playing with DAWs and other tools (admittedly a long time ago) and failing. Nothing about these tools will teach you why certain notes sound good together or why certain chords sound good together, etc..

For sure lots of electronic music just tries to skip all that completely though, or follows super strict genre rules where if you follow them it all comes out OK.

But we mostly agree though, the lessons are what make the difference. When I tried to learn this though there was zero accessibility of local teachers who would have taught through a DAW or something like that though. Finding a piano or guitar teacher was something available everywhere.
£200k a year you'll be very comfortable, and could probably get a mortgage on a £1million house depending on your deposit (downpayment)
Mortgage repayments are much cheaper than renting, at least where I am in London
There's going to be some overlap with my suggestions and other comments here, but I'll give them anyway. These are some thoughts that might be helpful.

1) I've known several great programmers who didn't have formal education and that definitely exacerbated their impostor syndrome. Try to be easy on yourself; as others have said here, it takes time to build up your skillsets and it's super easy to compare yourself with someone who seems to know more.

2) Maybe you aren't on the team that could help you grow the most. It sounds like you can hammer out code that does the thing you want to do. Going beyond that is about judgement and patterns and processes and experiences. The right team can really help you grow those skills. Does your team do code review? Do they do pair programming [0]? Maybe some sort of mentor relationship would be helpful?

3) I generally find solutions are easier to understand when I've personally struggled with the problem they are trying to solve. Look at code for problems you are familiar with and try to figure out what patterns/OOP concepts are being used in the solution. When you can wrap your mind around the problem, you can learn more from solutions.

4) Do you have an interest in the people/product side of software development?
If so, you could try to move into a neighboring field.
I've got a notion that a strong technical background would make it easier for product/project managers to do their jobs.

5) You don't have to be the best; most of us aren't :) if you enjoy the work you are doing and your employer and team approves of your work, then maybe you shouldn't stress about it? Work to improve your skills for the fun of it :)

6) Maybe pick a single language and focus on getting great at it. Preferably one that enables you to work on a passion project. All else being equal, Javascript is probably one of the best good to haves.

[0] - I've been programming for more than half of my life and I've only come to really appreciate pair programming in the last year. As a way of sharing knowledge, it may be the best approach.

Good luck!
If your compensation isn't higher when switching ladders, then it doesn't matter how much influence you have. It's a demotion.

To be clear, that's not necessarily bad.

Imagine your boss coming to you to congratulate you on your promotion, and then mentioning that your pay will be reduced by 10% because now you're management. How'd you feel about them calling it a promotion?
Too much bureaucracy for access to internal resources (api access, repository access, requisition of servers, google doc permissions, w/e) slows down ICs and is a sign of bad corporate culture.

There’s a difference between needing to ask for access to shared resources and asking for someone else to do work. So many corporations silo there teams so deeply that PRs from outside members aren’t even considered. Collaboration isn’t given anything more than lib service.
First, because there are regulatory problems (e.g. regulators changing the rules after the part of the plant they apply to has already been built). Second, because they're not being built at scale.
Yes, I do think what I've built is the beginning of a solution applicable to many other people. Not that the wave is over, the site is back up and you can see for yourself.
> This is actually the misunderstanding that the author is talking about

I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it.

> People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point.

So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure.

> Slowing down your adversaries and weeding out the low-effort attacks is still valuable.

Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers.

> That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said.

The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this.
I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.
> No. Losing friends through the "natural cycle of friendship" is just as traumatic or even more so.

Not like this doesn't happen to those people as well,
and in this case you are literally never allowed to have any relationship mature past a handful of years during a key time in development of social skills.

Grass is always greener, obviously there will be benefits the person that moved will have that the other didn't recieve, but saying they are the same thing just isn't logically true.
> in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate.

What's your alternative? Using return values? But then you are doing the bubbling, manually.

Exceptions offer a more elegant and less boiler plate approach to this problem: if your code can't handle an exception, just declare it in your signature and ignore it. This is really the best approach to this problem:

- The error cases are part of the function's signature (as they should).
- The language takes care of bringing the exception to the right handler.
- Your code can proceed with the assumption that all the values are sound.
Once again Netflix is crowned as the biggest of the Les Incorruptibles on the App Store by Apple since they can get away from not only the 30% charge as it is a reader app but is able to roll their own payments on the web and still scale to many users without in app purchases.

There are probably more apps / companies who belong to this group due to secret deals by Apple, but now Apple says: No 30% charge for apps who's customers are 1-1. That's it.

Charging at scale without the app store tax is disqualified. But not for the Les Incorruptibles.
Fire on the Mountain – Rethinking Forest Management in the Sierra Nevada (2018)
"But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", or fail2ban, which are all silly ideas."

I know who I am arguing with here but port knocking is not silly. It's fantastic.

When I say fantastic, I don't mean it solves all of our problems and obviates any other protections ... what I mean is, for almost zero cost[1] it adds a non-zero level of actual protection.

As a lifelong UNIX sysadmin, it is one of the few totally unalloyed security improvements that I have been able to add to my systems. I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.

I also recommend SMS alerts on successful knocks - SMS alerts that you should never see in surprise. This is trivial, by the way, as you can put semicolons in the knock command:

/sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22 setup ; /usr/local/sbin/timestamped_sms 4155551212 "knock from %IP% - "

[1] knockd on FreeBSD, 10+ years, not one hang or crash.
Is it 𝓘𝓼𝓸𝓹𝓸𝓭 𝓗𝓸𝓾𝓻 yet?

https://www.youtube.com/watch?v=pHxlZ4dTXug
I am a team lead and I'm definitely a manager - 80% of my time is managing people, not making technical decisions, that's more for technical directors(who in turn do not manage anyone). And why would managers be able to fire people though? I can recommend that someone be let go to HR, but ultimately that's not up to managers. The process takes at least 6 months unless for gross misconduct anyway, it's far too complex to be up to a single person.
If people are wondering why this was posted today, 9/11/1973 is the date of the US-supported coup of the democratically-elected government of Chile.
where can you find some of those nice stories?
At 2 seconds per word you're probably better off with speech recognition. But it wouldn't work in loud traffic.
re: performance, I am guilty of making a general statement when I should have made a much more specific one: It's not too hard to beat Java for numerical applications.

The root of the situation is that it's pretty easy for the dynamic languages to choose an unboxed representation on the back-end while still exposing a reasonably generic interface to the programmer. The ergonomic payoff there is immense. I submit, for example, that the just obscenely rich ecosystem of high performance data analysis packages that have been built on top of numpy just could not happen in Java. Java forces you to either accept boxing, or write specialized overloads for every specific combination of argument types you want your function to be able to handle.

Java does have some specialized numeric libraries, generally built using code generation, but they aren't widely used because the ergonomics aren't great, and building any additional general-purpose tooling on top of them requires still more code generation. And that's just not a fun way to work. It's brittle.
Optional<T> isn't a replacement for typed exceptions as you can't pass or inspect the error details.
Same. I thought it was just part and parcel with me being a procrastinator by nature. I'm sure that's part of why it resonates so much. But yeah, it's always nice to know you're not as alone in your head as you think you are.
Ok, we'll use your phrasing above. Thanks!
> Pretty ridiculous thought, right?

Yeah, because Apple isn't doing that at all.

What's more, it seems like the fee Microsoft charges for every sale in their Microsoft Store is also either 15% or 30%. (Source: the App Developer Agreement, https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE...)
This is a little new to me, but as described, isn't it like a form of a proof by contradiction?

I mean, it doesn't have to bring in "we wouldn't be here" questions of survival, it seems to be just of the form of...

(1) Question whether A is true. (2) If A were not true, then it would necessitate that B is true. (3) B is clearly impossible. (4) Therefore... A must be true.
Yeah, there needs to be evidence backing up a claim to extreme resilience. Invoking scifi scenarios and Turing completeness does not count. One can easily counter with the Fermi Paradox and only one species on Earth asking anthropic questions.
> If you look at the majority of private code bases in the world, they'll look like crap

I sometimes think that the first set of people working on most software are just trying to get it to work at all, with limited expertise and lots of duct tape. Then come some journeymen who have to add more things. And, well, when I am writing code it tends to look a lot like the stuff around it... things just get Progressively worse!

I am not a dev. I don't intentionally write bad code, but the code I write sometimes hits prod. I don't really know what "good" and "clean" really look like. Just "works" and "doesn't".
> Why would you work for less.

Because I am more than comfortable on my engineer salary and being a manager would make me miserable.
Perseverance is the name of the game, much like it is in everything else we do.

I’ve been learning Vim and Emacs concurrently with Doom Emacs. I find that if I don’t use the tools for actual work, where speed/familiarity is necessary, I become acclimated to the new environment and start transitioning to its use full-time. Just editing configs is enough to get familiar and it’s low-stakes as far as fucking things up goes.
We edited the title following kibwen's suggestion: https://news.ycombinator.com/item?id=24444812
Elm enforces this since 2014 at the package manager level. They are able to do this because since the language is pure, the compiler knows if a function's signature has changed. If you are changing implementation details that don't affect data transformation, then that would just be a dot release. I haven't actually published an Elm package, but from what I've read this seems like a great setup.
I still wonder why games are often treated so much differently than movies or shows today. They should've reached the same cultural acceptance by now and are often as much art as their non-interactive counterparts.
What about concerns about luggage contamination/bombs etc? Is there a contents verification step in checkin to verify that contents aren't illegal or hazardous? Are there hygiene procedures? Are you vetting storage locations to be sure they aren't also possibly strategic targets? Any thought to the service being used to anonymize drug/money/etc transactions?
I agree.

The only thing I would add is that it also needs to be maintainable - the obscurity should not impede the maintainer's understanding of the implementation.