skysight-inc/HackerNews huggingface dataset:
I don't think the whole concept of checked exceptions isn't a mistake, although the way they're implemented certainly is. In my experience, the problems with them almost always stem from one of two issues:

1. Built-in exceptions that are checked but should be unchecked, IOException being the main offender (I don't mean things like FileNotFoundException; I mean the kind you can get if the OS returns -EIO)

2. Lack of exception polymorphism, preventing you from doing things like l.stream().filter(SomeClass::somePredicateThatMayThrow), even if the function that you're doing it from can throw the same exception that the predicate can

I think checked exceptions would be great and nobody would hate them if those two problems were fixed.
> You can hide it by transforming that checked exception into something specified for your API. At this point, what benefit have you gained from SQLException being a checked exception? You're hiding that detail.

This is what you should do, yes. And I gained from SQLException being checked, because I am reminded by the compiler that I need to wrap it in my API's Exception value. If I can't handle it or don't think a caller of my code can/should handle it, I'll wrap it in an unchecked exception and rethrow.

> Here's another pattern that happens with checked exceptions in Java:

I mean... what do you want? You can't fix stupid. That's a really obvious mistake that should never ever make it past code review. I can shit on Java for making everything nullable and thus actually difficult to figure out if you should null-check something. But I can't shit on Java for someone writing code like that.
Maybe. Regardless of what my parent meant, a lot of people in these discussions imply that we never looked at prior art because we did not make the choices around the tradeoff that they wanted us to make. And we did look at many, many approaches. We just decided to not go in those directions.
One thing I despise is internal systems with self signed certs because setting it up properly is a faff or no one can agree on the latest and greatest way to do it.

Oh cool that’s fine I’ll just click away all the big scary warnings in my browser to access this page. I’m an engineer and know what I’m doing! It’s a super strong key anyway. Oh wait I’ll just send this link to Bob in accounting and tell him to do the very thing we’ve been telling users not to do under pain of ridicule for ages and then he’s now doing that 10 times a day and now all of https is pointless because he knows that ‘it’s probably fine to ignore it because I have to do that at work’...
Reddit was seeded by sockpuppets.
Packaging something for my own use (or my company's) is quite different.
Anders Tegnell and the Swedish Covid Experiment
Oddly enough, the old mechanical tracker organs required a fair amount of strength to play.
Zero net cost is certainly almost never a thing; but zero incremental cost is often a thing.

To further your alternate-port example: let's say you have some instances running on Google Cloud. GCP already has a big CLI codebase that they get everybody to use, which has a command `gcloud compute ssh` for connecting to instances, which already has tons of magic built into it. It would therefore be pretty easy for GCP to add additional magic — e.g. randomizing the SSH ports of newly-deployed instances, and then publishing those ports as project secrets in a way that the gcloud CLI tool can discover and use in the `gcloud compute ssh` subcommand.

The incremental cost of an approach like this is effectively zero: the DevOps folks didn’t have to build anything new to get this advantage, because they already built all the infrastructure required (i.e. spent the labor-cost you’d be spending) in the process of getting some other, earlier advantages.

In a sense, setting up a platform or infrastructure that's more complex/flexible than what you require at the time, is the opposite of "technical debt." Rather than saving labor now but needing to be paid down with later labor, it requires more labor now, but potentially saves labor later. It’s a bit like paying a retainer fee: you get less than you pay for (or nothing) up front; but in return, you get things "for free" later on. "Tech equity" might be a good term for this — it's what you get when you invest labor into your tech stack.
Information, incentives, and goals in election forecasts [pdf]
Steam used to be this way, I remember running skyrim without steam running. Would it change your mind if you knew EGS planned on going the DRM route in the near future (including for titles you just listed)?
Yeah, lutzifer was another X.25 hacker chatroom. I think it was based in Germany. I used to reach it via Telenet [sic]. In retrospect, I think it may have been run by a US government intelligence agency. Someone on there doxxed me despite hopping through a lot of relays that should have been nearly impossible to trace through.
I do really prefer, and recommend the Firefox version on extension's [landing page](https://cazadescuentos.net/).

As I have commented other times, I found the Firefox review process quite smooth, and the Chrome one, quite annoying, I even considered to stop pushing updates to chrome.

On the tooling, Firefox has great tools, and even good guides on how to make the extension compatible with other browsers.
The cost of not having SSH vulnerabilities is infinite because there is no way to ensure that.
Good point! I don’t see why languages don’t adopt pattern matching (unless the grammar really breaks it for whatever reason)
New research shows disproportionate rate of coronavirus deaths in polluted areas
Type erasure makes deserialization a pain. This has lead to multiple incompatible implementations of ways to indicate what a generic type contains on top of the existing type system. In practice it means using generic types on DTOs is a pita.
One wonders why such a mode isn't present from the onset - and why customers accept the lacking of such :(
Yes, this is one of my biggest pet peeves and largest disconnects when reading these threads. I dont understand how people can accept apples privacy and protecting the consumer argument when that has nothing to do with the app store. That is iOS itself and its permission model.

Do people really think app store approvers are doing malware analysis on apps and analyzing network traffic to approve them?
> I think you'll find that most people - and a number of leading law experts - don't consider click through EULAs for valid binding contracts and clicking next is not the same as signing.

If you feel like you're potentially a target of a lawsuit, the only opinion that should matter to you are your lawyer's and the the court's. Some EULA restrictions are not enforceable, but some definitely are. No US court has ruled on whether EULAs are binding, or not - so there is no precedence.
You can save $175,000 of that by generalizing and getting internet.sucks instead. A bargain!
I know that some countries like the USA make foreign-service personnel go back to their home country for a couple of years between assignments, so that they don’t “go native”. I wonder how many of those employees have resigned at that point, because they had already come to feel that whatever country they were serving in was more pleasant than their home country.
Avoiding the smoke – how to breathe clean air
No need for an electronic piano/keyboard. A cheap, small MIDI keyboard is just as good for a beginner. Or if they really want something closer to a piano, a larger or full 88-key weighted MIDI keyboard is still a lot cheaper than an electronic keyboard, while still likely providing the same or more value.

(For those unaware of the difference, a MIDI keyboard doesn't itself produce any sound, and instead produces digital MIDI notes which are received and played in [almost] real-time by a software instrument on your computer, such as a software synth running in a DAW like GarageBand or Ableton Live. An electronic keyboard can directly produce sound through headphones or speakers when connected to a power source. Electronic keyboards may support MIDI, as well. MIDI keyboards are generally much cheaper and lighter and, IMO, are just as good or better, with the only requirement being that you have to connect them to a computer when using them. They generally support USB.)
I don’t think this is at all true... I mean the PR changes 350-odd files and adds some crazy JIT engine. It’s hardly low hanging fruit... I don’t know enough about how this is implemented to say it will make future features harder, they even state in the PR maintenance is very important to the design here so I’ll assume it won’t be a weight around their necks.
If there was a sports-like betting site for future decisions that major open source projects are going to make, I would put a thousand dollars on "Cargo/Crates will implement namespaces."

The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change.

But, this is the nature of open source (and even startups). New projects start under the (oftentimes correct) belief that they can do something better, which experiences linear extrapolation into believing everything you do is better through virtue of being unlike what everyone else is doing. We see the end-state of Maven, NPM, etc; we don't see the war that those projects went through to reach this state. History is elided, forgotten, then repeated.
I'm a relative newcomer to Java, and, being a newcomer, I have put some effort into exploring as many corners of the language as I can. One that's proven to be a particular puzzle is checked exceptions. But I think I finally understand them now.

I quickly found that checked exceptions just do not play nice with any sort of functional-style programming, like the article describes. But the problem goes so much deeper than that. Checked exceptions are also, as far as I can tell, incompatible with an object-oriented programming style. More or less for the same reason that they interact poorly with FP. The fundamental problem is that checked exceptions don't really play nice with polymorphism or higher-order programming of any type.

Which takes us to the crux of how I understand them now: Checked exceptions may not go well with FP and OOP, but they make all the sense in the world if you're doing procedural programming. There, you're not trying to create deeply nested abstractions, and you're not messing around (much) with polymorphism tricks. The code's very lexically organized, with little in the way of dependency injection or higher-order programming. When you're programming procedurally, it's fine to be exposed to the implementation details of stuff further down on the call graph, because you're the one who put it there in the first place.

And that, in turn, means that checked exceptions are not really a mistake. They're just a piece of evolutionary history. Because, early on, Java wasn't really an object-oriented language. It was a deeply procedural language with some object-oriented features. It arguably still is, it's just that there's been a big cultural shift toward trying to take a more object-oriented approach since Java 5 came along and made it more practical to do so.
An argument against obscurity is that it adds additional pains for your "regular" users (as in developers/3rd party developers/app developers) while being a small deterrent against unauthorised users (as they will be able to circumvent the "obscurity layer" and replicate their method to other bad actors).

edit: In the first sentence "against" is not what I wanted to say: what I wanted to say is that it "downgrades it's effectiveness".
I agree that obscurity can and sometimes should be a layer of security.
Trackonomy Systems Is Hiring a Sr Full Stack Engineer
Want to be part of an exciting pre-IPO enterprise B2B company working on the cutting edge of internet-of-things, artificial intelligence & agents, blockchain, and manufacturing technology? This well-funded venture-backed company has an international footprint with our headquarters in San Jose, California in the heart of Silicon Valley. We have paying customers and are rapidly scaling.

We’re looking for a Senior Full Stack Engineer who is passionate about automation and process improvement to support a wide range of technologies and will be involved in the build and DevOps advocacy of strategic parts of our breakthrough IOT platform targeting exciting verticals such as automotive, aerospace, defense, healthcare, pharmaceuticals, agriculture, and logistics.
This is a great opportunity to get to know some very smart people in the Valley, learn about the coolest new technologies, and solve a broad range of exciting problems such as scaling up hardware products to mass production, developing artificial intelligence, security, and positioning solutions.
You will be a core engineer of our early stage team. We work on everything from machine learning, to security, to high performance computing, to IoT devices, to dynamic web apps, etc. Don’t be surprised if you get to touch every system while you work here, often teaming up with other team members on critical work. Some examples of projects you may work on:

What you will do:
In this role, you will be responsible for developing infrastructure for data collection, storage and web based user interfaces. Responsibilities will include developing and optimizing databases, creating web APIs and web pages for user interaction including user management, multi-dimensional data display.

Experience:
Knowledge of Azure/AWS cloud environment
Experience with various databases
Know front-end and back-end web technologies including React, HTML 5, CSS, Javascript and Node.js
Minimum BS in computer science
Obscurity is double sided. While the attacker can be hindered by it, so is someone who can audit the defense and find its deficiencies. I always thought that was the main argument for avoiding security by obscurity - the benefit of better audit and improving defense overall outweighs the benefit of obscuring it.
Yeah, GP is saying you as the developer should not use random variable names. Let an uglifier select random names for you.
The costs and investment are not unrealistic or unreasonable. Apple paid those costs. Google paid those costs.

There’s a difference between saying “it would be really hard for Epic to recreate an ecosystem and hardware like Apple’s distribution channel” vs “it is structurally intractable or unrealistic in any way.”

If Apple & Google slogged through a decade of developing devices, app stores, manufacturing, etc. then so can Epic. If that’s really hard and Epic doesn’t want to do it, they can play by app store rules and use existing app stores.

The fact that it’s hard and expensive for Epic to do it their own way is no excuse to call other businesses monopolies. They aren’t doing anything that structurally stops Epic from building its own thing if it wants different policies.

Your argument is specious. It’s like saying the suggestion of building your own toll road is too hard, so some other toll road operator (who sunk capital into making their toll road) suddenly has to let you use it for free.

If they built the toll road, and they aren’t structurally sabotaging you from going and building your own if you don’t like the tolls, then this is your problem, and the other party exists as living proof that “this is hard” is not an adequate excuse.

You can’t cry monopoly just because you don’t like something and feel it would be hard for you to do it a different way on your own.
Internally, we phrase it as "Make the system objectively hard, then don't tell all the details". Wasting an attackers time is a fine goal.
That's just because we didn't drive the pests to extinction and we didn't make the massive long-term investment in greenhouses. Had we done either, all-natural crops would be able to feed the world.
Because if you are a small player you have a smaller team and can more easily take those decisions.

This is partially based on personal experiences, when I have worked in small organizations I can get a change through by just proving it works but if it's within a large organization then there are a lot more people to convince and the processes take a lot more time.
I have less experience with CPAN and RubyGems but npm's namespacing system has two very serious problems:

1. It was introduced very late, meaning the community had already formed patterns of contribution around a flawed flat system. This is a problem of the flat system, not of the namespaced one.

2. It is still to this day entirely optional (for understandable backward compat. reasons). This gives namespaceless packages a misplaced position of authority over namespaced ones, which erodes the value of namespacing.

These are tough problems to get around if you start with a flat structure, but they really just outline the urgency of switching to namespaces for a relatively young project.
Could take up goat farming.
> I've come to realize I'm not very good at it and thats unlikely to change.

Citation needed.
We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm.

Don't those package registries all suffer from not having namespaces? RubyGems in particular [1].

[1] https://thehackernews.com/2020/04/rubygem-typosquatting-malw...
No mention of port knocking for SSH. I used to be scanned constantly for SSH logins. So I changed the port. The login attempts stopped for awhile, but eventually they found the port. Now with port knocking, I haven't seen a single attempt.

Security by obscurity alone is bad, but as another layer, it can be great.
Defending unchecked exceptions with bad iterator interface design is a little weird.

`next()` should return an option that you can `map` over.
You could do that without a plain-text password, though with a salt it would be harder (though you could still do it proactively by checking the password when the account is made).
Suppose we recover "Greek Fire" (as an example, any of the inventions could be used). Since Intellectual Property is so very important, who gets the rights to it? It seems unfair to the descendants of the original inventor, who had the seminal moment of conception, to give any money to someone who merely re-discovers a concept known to exist, just not ever written down.
Explainer: L1 vs. L2 vs. L3 Cache
For true beginners even the easy single command might not be easy. You need to be familiar with the command line, you need to install the aws tool and hope that you don’t run into issues (often times if you’re on Windows installing command line tools can involve extra hoops for example), you need to navigate the AWS dashboard and get familiar with their unintuitive terminology (to host a site you need an “s3 bucket”), then you also need to create a key for your client and learn what a key is. Individually those tasks are not that difficult, but when you’re a beginner it adds up and quickly becomes intimidating.
It's very dangerous to drive and write at the same time, I don't see how this is usable
I agree with a lot of this perspective. It's also directly relevant to our situation, because we are basically in exactly that place now, and dealing with these problems is something that proponents of adding namespaces need to navigate.
JFC. It's 2020. Natural language processing is ubiquitous. And clowns like this are still denying service based on keyword matching. Get better programmers, Paypal.
But the examples given won't help and is just bad advice in general.

- Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there.

- Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.

- Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In your code? Don't assume obfuscating your code and/or randomizing variables will protect your encryption keys.
Creative Xchange offers free virtual concerts 12th September
Agree. I think this is typical 'small guy landing big punch attitude'. I see this is common for languages which have not yet achieved (real or perceived) popularity.
Not baaa-aa-d.
To maybe give some perspective _why_ security people say that security by obscurity is bad - and especially serving ssh via port 64323:

Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible.

There is more housekeeping to do. In case of a handoff, things like this need to be documented. If all services work on their default port, there is no need for documenting them.

In the case of compromise, it becomes very hard to identify how a machine got compromised.

Yes, a lot of people do not do a full port scan. But those are not the people exploiting risky vulnerabilities. Security by obscurity reduces your risk, but only to a certain extent. Having a proper patch management or firewall management in place reduces your risk a lot more.

A lot of owls do get killed by humans, despite their camouflage.
This is amazing. Huge props to Lukas Larsson and the OTP team!

Some background on the journey to BeamJIT:
https://drive.google.com/file/d/1hHCs90kDX_wJ9AbLzGNu5bZKdIV...
Bigger shocker here. I hope Rivian doesn't follow the same path, but I can't seem to find any real videos of their truck doing what they've been saying it's capable of either.
I mean crypto is based on security by obscurity if you think about it. It's just REALLY obscure.

You can technically compute the private key for someone's Bitcoin wallet for example. It's just you'd hit the end of the heat death of the universe by then.
While I have heard a lot of good things about Sorbet I would still hesitate to use it with Ruby 3 and it's type language RBS around the corner.
> I have basically no CS knowledge

You could take some computer science classes, then you'd get some CS knowledge.
IT should have a system of roles and permissions that allows administrators to log in as other user if necessary to install updates or reset passwords. This access should be logged and ideally periodically audited by a 3rd party. Sharing a password is dangerous because it is impossible to determine who used the password to perform a malicious act.
https://freebsdfoundation.org/get-involved/project-proposal-...
Interesting, thanks for those details. I thought the whole point was to be cheaper/easier than HDD, at these prices, why not just drill?
Everything has upsides and downsides. There are downsides to the Rubygems approach.

However, typosquatting is an orthogonal problem to namespacing, you can still typosquat a namespace.
It’s a very tempting career change some days!!!
I was looking into AC again today and noticed that there are some unofficial patches, one of which allows you to freely configure the resolution. I'm sitting here playing Alpha Centauri at 1080p and I couldn't be happier.

Yitzi patch: http://alphacentauri2.info/index.php?action=downloads;cat=2 (you'll need to download 3.5 and 3.5d, then overwrite the terranx.exe in 3.5 with the newer one from 3.5d)

Graphics patch: https://github.com/DrazharLn/pracx

Requires Alpha Centauri with the latest official patch (GOG version comes already updated).
You're describing what was, not what could have been. There's nothing to preclude just having a function on your classes to read from json or db data.

Perhaps the culture is stronger than the language though.