Hacker Newsnew | past | comments | ask | show | jobs | submit | cdirkx's commentslogin

Somehow I was able to place a pin in Quebec, which resulted in a ray of 2058 miles to the USA northwest


I did immediately consider setting up a prediction market willpayfornoreasonpayout.com


It doesn't even need to be government-run, we just need the right incentives. I've seen proposals for making some kind of data loss insurance mandatory to compensate victims. The insurance companies would then conduct audits which determine the premiums for the company, and investigate for negligence after a breach.

Edit: Thinking more about it, this would probably also be positive for security investigators. If a company is stonewalling you and ignoring a legitimate bug report, you now have the option to escalate this to the insurer. Maybe they could even facilitate bug bounty programs for smaller companies


I've had a similar thought in the past. I was thinking about the feasibility of a law being introduced where each company making over a certain amount of money per year must begin a VDP (and optionally a BBP) so that security flaws can be reported to them easily. This can easily be done by simply opening up security@companydomain and using security.txt (https://securitytxt.org). Reports must receive a response in N days, where N is calculated based on available staff, resource allocation, and revenue of the company. If they don't receive a response after N days, this can be escalated to some government agency which can take action against the company for failing to respond to a report on time.


If something like this had been implemented 20 years ago, we'd probably be exactly where we are now. What's the point?


Yes, they are immutable. It's only possible to "yank" a specific version, which will prevent new dependencies, but it will still be available for download for existing dependencies.

https://doc.rust-lang.org/cargo/commands/cargo-yank.html


To elaborate on "prevent new dependencies", dependency resolution will never choose a yanked version. However the yanked version remains hosted.


The argument is that Silksong will completely absorb any potential market for you new indie game had during that period. People will be too busy playing another game, leading to poor numbers during launch. It's hard to recover from that.


Right, but what does that have to do with "every other developer has to time their release and development around GTA 6", especially considering that Silksongs release was a surprise, so what exactly could you even plan for?

My original point that there is so many things at play, GTA 6 launch date, which may move, together with other things outside of your control, that "planning your release and development around GTA 6" doesn't make sense, unless you're a big company doing a AAA release.


This implies Silksong was the stronger title, either in gameplay, marketing; or both. If the indie game was better, people would be playing that over Silksong. Isn't this just market forces applied to games?


That’s the point. If possible, you don’t want to release your game at the same time as a much stronger title.


I'm saying that's defeatist to your game. Have faith yours is the stronger title


You should also be mindful that there are marketing budgets you can’t outcompete.

Even if your game is better, you’ll probably make much more money if you don’t time it to launch at the same time as the new GTA


The problem is that technology exponentially increases the negative effects of bad actors. The worst a sociopath could do in the stone age was ruin his local community; while today there are many more dystopian alternatives.


I don't think that is true either. There have been despots throughout all of human history that have killed huge amounts of people with technology that is considered primitive now.

Whereas much of the technology we have today has a massive positive benefit. Simply access to information today is amazing, I have learned how to fix my own vehicles, bicycles and do house repairs from simply YouTube.

As I said being cynical is being intellectually lazy because it allows you to focus on the negatives and dismiss the positives.


I don't think this is unique to code, but a limitation of filesystems in general. You could make the same argument for photos: I want them sorted by date, by tag, by person in the image, by location.

I can do this in Lightroom or my "Photo" app, but then you are always reliant on some third-party tool. It would be nice if there was some native way for files to not have to commit to a single hierarchy, but able to switch views on the fly (without it being insanely slow for larger amount of files).


By explicitly being obviously a scam, scammers can preselect for the most gullible people


Quite some years back I worked with JetBrains MPS which used a "projectional editor" instead of a text editor. It was pretty neat to be able to enter "code" as mathematical expressions, or even state machine tables or flow diagrams with actual nodes instead of a text representation.

Sadly not much has happened in that space since then, but it was cool to think about what our tools of the future might look like. (of course ignoring all the practical reasons why we're probably still using regular text files in 100 years)


As a secondary effect it kind of is; the general assumption still is that the slop-generating AI will need a lot of power to train, so there is surprisingly a lot more private investment into fusion and fission innovation in recent years.


Well, AI also has something else for it : at this point, no one is expecting any ROI soon, but they all imagine that it's going to be huuuuge, so the "expected" (as in, "wished for") ROI might as well be infinite.

As soon as AI investors start demanding dividends, then the ROI of investing in AI will be compared to the ROI of investing in electricity production "for production sake".

Even if we shut down chatgpt, people who still switch light on.

If we only keep enough fusion reactors to run LLM inferences, but no one can afford lights, well...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: