skysight-inc/HackerNews huggingface dataset:
My beard is not grey enough to know about how the Security by Obscurity meme/mantra have evolved in the tech community.

But one thought I have is that this more nuanced picture is much more complicated to tell beginners. Beginners / not as security conscious developers often, wrongly, assume that obfuscation is much more powerful than it is.

The safest digest of the "Apply ≈Kerckhoff's principle, but some obscurity on top of that is not a bad idea if it's cheap to implment", is probably "security by obscurity is bad!1!".

Certificate pinning or sandboxing in mobile apps won't stop people from reverse engineering your API's. But if your personal belief is that it's like almost a state actor level attack to see your API routes or modify requests, it will undoubtedly influence how you implement them.

I've seen some serious problems where companies do really bad things (like sending the ID of the currently logged in user and not checking it server side, allowing for execution as arbitrary user), which I guess at least partly arose from thinking along the lines of "It's only our signed code that will ever make these requests". Even bad developers wouldn't make the same misstakes in ≈2020 on the web, where the understanding that the client is untrustworthy have fully statured the common understanding.
Performance is why you should use different implementation details on the metal. The reason why there's a distinction at the language level, though, is because Java's designers chose to leak implementation details into the language's high-level semantics.

This distinction wasn't such a big deal in 1995. It was perhaps even the preferred way of doing things according to contemporary values. Nowadays, though, Java is a very different language that lives in a very different cultural milieu. So, nowadays, the language-level distinction, in combination with some other design decisions that came later, is absolutely a source of performance problems. Any code that tries to do things like store numbers in one of the standard collection classes will quickly devolve into a horrible mess of memory overhead and pointer chasing. It's led to this perverse situation where it's honestly not too hard to beat Java performance in a dynamically typed language like Clojure or Python, simply because dynamic languages make it easy to encapsulate the implementation details (and therefore to choose a more performant run-time implementation) in a way that Java's type system doesn't really allow.

You can still keep Java toward the top of the well-known performance benchmark leaderboards, but only by coding as if Java 5 never happened. Which is an option that's only tenable for toy use cases like benchmarks.
Ask HN: When an iPhone is released how far off are Apple in the next gen iPhone?
e.g. the iPhone X was released September 12, 2017. At that same day, how much of the next gen iPhone (iPhone XS, released a year later) had Apple already built?
You have a point but two wrongs don't make a right.

Also, the escalating violent struggle is making someone some serious money. So the monetary incentives are just as strong too whatever the overt justification may be.
PayPal blocking transactions containing the word “tardigrade”
What library are you using? The pattern you are trying to achieve should be achievable in principle. This pattern is commonly called "scoped" threads (or "scoped" async tasks in this case) in the community.

The problem might be that if the executor you are using doesn't guarantee in its type signature, that the task you are trying to launch doesn't outlive the lexical scope there, the compile gets rightfully angry. There are some executors that guarantee that; see here: https://docs.rs/async-scoped/0.4.1/async_scoped/
It's crazy to think how much ICANN made off application fees for each of these.

What do they do with all that money? Is it really that expensive to do what they do?
why do we always say it's "imposter syndrome". not everyone can have "imposter syndrome". some people are actually imposters
Breakthrough Starshot Initiative (2016)
If curious see also for your Minitel needs:

2018 https://news.ycombinator.com/item?id=18781820

2018 https://news.ycombinator.com/item?id=16263093

2017 https://news.ycombinator.com/item?id=15401405

2017 https://news.ycombinator.com/item?id=14681561

2017 https://news.ycombinator.com/item?id=14577881

2012 https://news.ycombinator.com/item?id=4175141

2012 https://news.ycombinator.com/item?id=4170531

2012 (1 comment) https://news.ycombinator.com/item?id=4088360

2011 https://news.ycombinator.com/item?id=2733106
The focus in that sentence is not "a large number of packages," but the "in an automated fashion."

Plus, that's only 100 packages. There are people who legitimately maintain more crates than that.

> would the crates team be more open to transferring ownership of these packages?

https://github.com/rust-lang/rfcs/pull/2614
If you can read and tweak code, you are already useful for 90% of necessary work. For maintenance you have little need for OOP concepts. 95% of code out there is crap anyway. What matters is: Is it being used / is it useful? If you can manage to create such code, you are already competing with the best of the crap. There's never enough time and money to do it right anyway, don't be too hard on yourself.

Recognize how powerful circumstances always are.

There are things you can do to improve or feel better. It needs to be deliberate and you need to care enough to put extra effort into it and manage your training as you would do a project.

Lots of talks on youtube can provide pointers and inspiration. But it's hard to get the chance to put it to use. A hobby project would provide that opportunity, but it need to be something you really want to do and something that will provide you some value.
I think this feeds into my pet peeve that program source code shouldn't be text. The need to have everything spelled out in a readable fashion in text files is a major facilitator of boiler plate code in many situations (like long throws statements in Java). More semantic representations of source code have the potential to be more selective in their handling and display of such things. There would be more ways to show automatically deduced information or to filter out code/information that is irrelevant right now.
> They're not trying to pull customers off Valve [...] There's a difference.

Assuming this is true, is it a difference that matters? If the Epic games store didn't exist, Valve would not be stepping up and offering those games for free right now. The reason those games are available to you for free is because the Epic store exists.

As a consumer, I would have a smaller selection of discounted/free games each month to choose from if only one storefront existed. If Steam was the only platform, I wouldn't have been able to get Into the Breach at 50% off when I wanted to buy it.

Whether you think that's 'competition' or not -- I'm not going to argue over definitions, but whatever you want to call it it's good for consumers. You're still getting more stuff for cheaper just because another store exists.

> However, the discounted price while it's on sale is.

Same question as above, does this distinction matter? Would we say that Xbox and Playstation aren't competing with each other just because games generally sell for the same base price on both platforms? In reality, the price I paid between two stores was different. Why does it matter what the base price of the game would have been in a theoretical world where it wasn't on sale?

The end result of all of these situations is the same: as a consumer, I'm getting a greater variety of games at lower prices. The end result is that when I buy a game, there are pretty good odds that it might be discounted or offered for free somewhere at the exact moment that I want to buy.

And this is even ignoring the other perks you get from multiple storefronts such as the fact that you don't need to install a client to download games from GoG and Itch (not a service that Valve/Epic offers), or that GoG is going out of its way to track down rightsholders and get older games updated to run on newer systems (also not a service that Valve is prepared to offer), or that Valve is prioritizing Linux compatibility layers (which neither GoG or Itch have the resources to prioritize), or that Epic is subsidizing smaller studios and paying to get exclusives like Journey off of consoles and onto PCs (which is a service that nobody else is prioritizing right now).
So what you're missing is the 'drilling-in' you get from a CS program. Don't worry! You can do it to yourself in much less time. The rest sounds like consequences of that as well.

First, start a memorization program. This means Anki, really. Start putting in the basic OOP concepts you've forgotten that you feel you should know. Then put in more as you learn it.

Second, start reading up books on interview questions and (a) practicing them and (b) shoving facts to memorize (complexity of algorithms, basic implementation notes for common data structures) into anki.

Third, you need a project that stretches your skillset and lets you work deeply with areas that you need development on. That's either a low-priority side project at work or something at home.

What you're describing is exactly what's normal for engineers I've met who didn't get a formal degree. Nothing that can't be fixed with a bit of studying and practice. Honestly.

If this all fails, you can always play MIT open courseware at 1.5x.
How does success in product hunt relate to success with a product?

To what extent do "product-loving enthusiasts" overlap with people who will buy your product?

I get the impression that that person (the author) is concerned with self-esteem and upvotes are the currency of that.

On the other hand, to make a sustainable business where you can deliver the product to people you will concern yourself with cash as a currency and the discussion is going to concern an entirely different constellation of objects.

Cocaine bypasses the motivational systems in your mind by targeting a population of 20,000 or so neurons in the brain. The "learning" that it gives you is that cocaine makes you feel you increased your utility function. If you're a really good student you'll understand what happened and learn "don't do cocaine."

Social media is like that.
Knowledge generally isn't something you brute force.

If your solutions are bad, read a book on Lisp (that wasn't intended to be a pun, even if On Lisp was a good book and would fit the bill).

If you're not planning on leaving the OOP space, read a Smalltalk manual. It'll probably stick more, and I've never read a Smalltalk manual that was worse than contemporary books on OOP.

Knowledge is a problem that can be solved programmatically: profile where your bottlenecks are, then read until you understand the topics.

It doesn't sound like you've had any formal education (from the hobbyist comment), which actually means your situation is pretty hopeful. There's a lot of low-hanging fruit for people without formal education to grab that can sometimes even double their abilities. Grabbing a book on algorithms would probably do you a world of good.
True, but you can further break architectural decisions down into those that are easy to change and those that aren't. If something is easy to change you may as well implement the simple version first.
Buglighting. (Bug + gaslighting).

"You don't actually have that problem. The system doing that is expressly a feature for you."
> I wonder if the technical stack you are working with is not a good fit for you.

That's a good point. I quit all of web dev because I couldn't stand the culture of constantly shipping dynamically typed code and being unsure of whether I typo'd a variable name.

Now I work more in systems programming and find it much, much more sane, if more difficult at times.
Java was my introduction to namespacing, so I only suspected but didn't know for a long time that Java overdid namespacing.

Companies change names, they merge. Sometimes they go out of business but stick around as a foundation stewarding their old projects, and you might be going to example.org for years for documentation on a com.example module.

And the namespaces weren't enforced (who is going to stop me from publishing a com.example.foo module?), so it expected much and delivered little.

No namespaces is bad. Five level namespaces are better, but still bad for different reasons. Two might be good. Some might prefer three. But zero is right out.
Work from home, take breaks, do simple exercises
World is working from home. they sit for a long interval of time.

Visram is an app that aims to make ourselves more active by reminding us to take breaks.

interactive exercises that helps you be healthy.
People who can pass the whiteboard interview might have a problem persisting on long, not very challenging grunt things. Migrating that database over a period of a year. Overhauling some bits of that terrible UI. If you are already employed, look for the opportunity of improving something terrible that no one finds sexy enough. The role will be appreciated.
Found an old video on my computer and decided to repost it
You’ve taken a comment that adds something to the conversation (a conclusion about build times that you agree with), grabbed a tangential aside about good libraries and spun off a flamey side-thread by going after internal library authors as being delusional, done that god awful cherry-pick “>” citation thing, made repeated appeals to authority about your extensive experience, cited zero examples of OSS libraries to make a substantial counter point (which can be done), ratcheted up the temperature first with NIH, second with disparaging remarks about new grads, and finally with a bizarre contention that I must be angry that I can’t get a job at a place I got a job. All the while I’ve made all my points under my own name, and you’re safe behind an alias.

Your profile lists you as a moderator. Why are you throwing fuel on this instead of steering it back to the technology as I’ve repeatedly tried to do by bringing up actual examples of actual code? In spite of a 12 year tenure as a site member I comment pretty rarely because there are only a few topics where my perspective is all that unique, I don’t care about karma points, and the odds that someone is going to pick a fight make it easier to just get back to work and not risk it 99/100 times. You’ve succeeded in sending me back to the orange bar for however long, so mission accomplished: someone is still wrong on the internet but you’ve driven them off their cookie.
> The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration.

As you already mentioned, that ship has sailed the second you decided to use Java. Every function already has to be wrapped in `class`, which is obnoxious.

> See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?"

My point wasn't celebrating boilerplate. It's about having a statically typed language. If it's too much to either add `throws Exception` to your function signature or to write a try {} catch {} block, then it must certainly already be too much to write `class MyClass { void myMethod() }`, no?

> If there isn't a return value, I don't.

You still have to write `void`, don't you? And checked exceptions are supposed to be something you want to force on callers of your code- like a return value. You don't want to return anything? Then return `void` and don't throw any checked exceptions.

> Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions?

Because it's part of your API. If you write:

`int fooMethod(int input) {...}`

Then you are saying "If you call `fooMethod` with an int you will get an int." If you always throw an exception on input == 3, then your API is now lying. You should either return a type that encodes the possibility of not being an int OR throw a (checked) InputWasThreeException, to be honest to your caller.

Java is a poor language. Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately.
From the article:

This is not the first time typosquatting attacks of this kind have been uncovered.

Popular repository platforms such as Python Package Index (PyPi) and GitHub-owned Node.js package manager npm have emerged as effective attack vectors to distribute malware.

"Orthogonal" suggests no connection but what I see above is a list of package managers that don't have namespacing.
Why not start writing tests, follow best practices, read a book and try to internalize the knowledge etc?
Oh, thanks for the heads up! I don't send spam - I've just sent 01 email so far. lol

I've been using the Buttondown.email service. But will move to a custom domain to improve deliverability.
Poor people need a bank account, fact. They need to get to their job, fact. Public transport is the most affordable way to do so, fact.

Or do you believe many entry-level jobs pay in cash and are at walking distance from places working class people can afford to live in?
It is not a comprehensive list of things considered, it is a list of successful ecosystems that we decided to pick something closer to, than others that we decided not to.

And even grouping those together in terms of downsides is not really doing justice to the individual problems that each of those systems deal with.
Paypal's transaction filters have seemingly run into the Scunthorpe Problem[0] and have concluded that a microrganism[1] is offensive.

[0] https://en.wikipedia.org/wiki/Scunthorpe_problem

[1] https://en.wikipedia.org/wiki/Tardigrade
Being mediocre or bad at something is not the reason to left.
The reason to give up is if you do not want to do it anymore.
Tip for 20”x20” filters on a 20” box fan: Put the filter BEHIND the fan.

The suction will secure the filter to the fan, and you’ll also keep dirt off the fan motor and blades.
This is all answered in the: "Why store your luggage with BagsAway" section on the linked landing page.
To me all these slogans around security is to ensure people really, truly, actually think about things before they go against the grain. Is using obscurity as part of your defence always wrong? No, but equally it often adds a false sense of security. Popularising these easy to remember slogans helps change peoples defaults. Nowadays, if someone sees an attempt at security by obscurity it (hopefully) rings alarm bells and causes them to interrogate it to ensure that there is also other security measures in place, or that it is otherwise OK. It's the same with "never roll your own crypto"

I find it somewhat interesting that the article uses an example which falls right into another pitfall that "security vs obscurity" is trying to prevent.

> SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised?
>
> Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. ... So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.

This is technically correct. However, the author has identified a security concern that he wants to mitigate: brute force attacks. Now, you could try and reduce that risk by using a different port which might reduce it by 50%, or* you could fix this issue by deploying fail2ban (or using ssh keys, or VPNs and bastion boxes, etc), and thus negating that attack vector entirely. There isn't even a usability argument here: making people remember the right port for ssh is less usable than setting up fail2ban. Of course there are tonnes of other attack vectors to consider, but in general where possible its better to "properly" (fsvo.) mitigate those concerns and only rely on obscurity where that isn't possible. If a concern is mitigated than adding obscurity does almost nothing, while likely proving to be more annoying to the end user (like in the case of specifying a port in the above example).

Now of course that's not to say that you should never use obscurity, but if you do then I think its entirely reasonable that you are prepared to give a good justification why its appropriate. For example, sharing via secret URLs is a good example where it can be easy to justify in some settings, but it equally may not be OK for documents that are really really sensitive as its relatively easy for links to be shared in error with the wrong people.

RE some comments about using obscurity to signal that your deployments would be harder to get into and thus for attackers to not bother: I'd genuinely love to know if that is true or not, I wouldn't be surprised if attackers assumed obfuscation mean that the more advance security measures hadn't been deployed (otherwise why bother with obfuscation?).

* Based on the twitter poll in TFA, though if you have a targeted attack it seems sensible to assume that if port 22 doesn't work they'd try again with other methods
They're verifiably hard to guess. That is fundamentally different.

(At least when passwords are generated with enough entropy.)
Maybe the test should be: "is my system considered to be secure even without any obscurity?" If the answer is yes, then add obscurity.

For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right?

Now you can change the port. Change the SSH banner and hide the version. Add some port knocking. And so on. None of these measures would work by itself, but they will discourage non-targeted attackers.
>the UK is recruiting a Government Chief Digital Officer (GCDO), who will be working at the highest levels of the Cabinet Office to lead the digital transformation of public services in the country. All of this and more, for £200,000 a year.

Maybe the reason they can't find anyone to do this is that they are underpaying for the position. The responsibilities described sound at least at the level of a Senior VP, if not higher, at a large tech company. Those positions typically pay more than 10x that compensation. In addition, being in government comes with its own unique set of headaches and scrutiny that people in the private sector would not have.
The processes are a legacy of distributed development in the era of dial-up internet. No always-available services, no github, not even any requirement for version control. With every package being maintained independently. While most packages do now use version control, every package has the potential to use a different system, and internally could use a different set of tools to do the actual packaging work.

If you were to design the .deb packaging workflow today, you'd do it very differently. You would probably have a single, or much smaller, set of source repositories, and you would have a single tool to do all the core packaging work.

You only have to look at the BSD Ports, MacPorts, Homebrew, vcpkg, and other software collections to appreciate how extremely complex the Debian approach is, and how the other systems benefit from a strictly standard set of functions to do their job, making all packages uniform and easy to work on.

On the other hand, because of these considerations, Debian has vastly better support for complex versioned dependencies, and the SAT solver in apt is best in its class. The other systems manage the collection as a whole and don't need to care to the same extent.

So I would agree some modernisation wouldn't go amiss. But it's difficult to accomplish that when you have a 25 year legacy of doing it a completely different way. And you have over 20000 packages to fix.