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

> And why the hell would anyone want a job where a mistake results in personal ruin?

People will do nearly anything if the price is right.


Yes, there are some people who thrive on risk and will do things like jump off a mountain in a wing suit just for the thrill of it. That doesn't mean making that sort of personal recklessness legally mandatory for employment is a good idea.

This sort of personal liability OP is proposing would just ensure the security industry is dominated by highly compensated compulsive gamblers because nobody else is insane enough to take the risk. It's an absolutely ridiculous idea.


The most reckless will, of course; but most people won't -- they just won't do it.

Corporations evolved the liability structure they have today so that large undertakings, where many people have to work together and where the bad deeds of a small number of those people could sink the undertaking, were something that regular -- people who can't self insure -- could be a part of, as investors, managers, staff, &c, &c.

Limited liability may make accountability too narrow; but blanket personal liability makes it far too broad. It's not a solution for running a large, complex economy in a more accountable way.


And 70 years ago I would agree with you, but now we have a handful of individuals who are the economy with wealth that's rivaling nations. Something has gone awry.

What does that have to with assigning liability to managers as proposed?

It seems like the handful of people you're talking about are totally different people.


The primary goal of all basic sciences is human understanding. "Truth" is no more a goal for mathematicians than the physical laws are a goal to physicists; they simply exist in nature. The goal is rather to develop useful language and conceptual frameworks for reasoning and communicating. That understanding underpins all practical applications.

Sciences don't have goals, people have goals and they differ. Some are fans of pure math as a kind of religious or almost erotic activity in elegance and beauty, others are application minded. Some are in it for the community and outreach and conferences, some are in it to just sit in an office alone and be left alone to do it in a zen like flow state all day and night. Some treat it as a 9-5 to pay the bills with a skill they happen to be fit for but aren't especially passionate about.

How do you normally verify the work product of a "few-shot" development process? Do you scrutinise the source code like with human developers? Or do you just run the test suite and click around the app to check if it seems to work?

I haven't done it in a production project - this will be the first time for me. I have specified the architecture and data definitions pretty well. The tests will be run against the customer's Excels, which is what the warehouse will be replacing. I'll check the general shape of pipelines, models, orchestration code, etc. but in many parts I probably won't review the code myself.

Since OpenAI is undoubtedly also under economic pressure, why is it still hiring humans for Account Associates, Android Engineers, Data Scientists instead of demonstrating its AI prowess by automating those roles?

https://openai.com/careers/search/


To use the humans to generate training data for the AI to learn from.

> He’s also always argued that mathematics is fundamentally about human understanding.

It's also worth pointing out he didn't come up with this viewpoint just to "cope" with the headlines. Thurston articulated this way back in the 90s (https://arxiv.org/pdf/math/9404236) and also more recently (https://mathoverflow.net/questions/43690/whats-a-mathematici...):

> The product of mathematics is clarity and understanding. Not theorems, by themselves. Is there, for example any real reason that even such famous results as Fermat's Last Theorem, or the Poincaré conjecture, really matter? Their real importance is not in their specific statements, but their role in challenging our understanding, presenting challenges that led to mathematical developments that increased our understanding.


> I thought the reason we were encouraging people to go into STEM, and providing clever people with large salaries, was that mathematical results were of practical value to the wider human race. In which case, it’s surely very good news that AI can get those results.

The impact of mathematics on other disciplines goes much further than specific results. Just as important, if not even more so, are the language and ways of thinking that typically come out of the process of establishing those results. Results without the accompanying conceptual understanding are about as useful as a mere oracle for math theorems.

Another point that seems to be frequently missed or mischaracterized is that mathematicians are not opposed to computational tools as a matter of principle and in fact do use them when they help their research. The current controversy is not about a hypothetical future where mathematicians have easy access to open-source, open-weight, auditable natural-language assistants to help them internalize a new result or search for counterexamples. It's primarily about the recent behavior of certain for-profit companies suddenly trying to disrupt mathematics by caricaturing it in the public eye as a game they can "solve" or "beat" for headlines and valuation.


> The impact of mathematics on other disciplines goes much further than specific results. Just as important, if not even more so, are the language and ways of thinking that typically come out of the process of establishing those results

What makes you think so? I can think of lots of specific results that helped e.g. economists - convex optimization or supermodularity, say - but I don’t think the broader way of thinking of mathematicians has had any input into economics for the past fifty years, and arguably nor should it - the discipline can think for itself. Similarly, sociologists can use linear regression, or geneticists can partition variance, without having to think like mathematicians.


> Math, on the other hand, was paid for because people and states believed progress in math might lead to meaningful improvements in other branches of science, and, in turn, in our lives. If this is better served by AI, should we keep paying for the same number of tenure positions?

That is a pretty huge "if". The ultimate purpose of mathematics and really all scientific inquiry is human understanding of the natural world. It's not at all clear whether large language models can replace that any more than calculators can replace human mastery of arithmetic. Is society ready for engineers to design bridges and airplanes without understanding the underlying mathematics by simply handing off the entire process to a black box "AI architect"? Are people ready to ingest drugs "vibe-designed" by human drones pushing buttons on an "AI drug discovery" machine and just going "meh, seems about right!"

It might also be useful to take a step back from the hype that the frontier labs are obviously incentivised to incite. Before speculating about how "AI math" capabilities might supplant cutting-edge research in mathematics and other sciences, take a look at OpenAI's own job postings (https://openai.com/careers/search/?). Why doesn't OpenAI demonstrate its world-beating AI capabilities by automating more routine roles like "Account Associate", "Systems Architect" or "Android Engineer"?


Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?

> Where do you draw the line between system packages and user facing apps?

If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.

I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.


> I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.

Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?


> Are you saying that Silverblue-based distros are noticeably more stable than Fedora?

TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time.

Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).

It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.


Thanks for the input!

> I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).

Two follow-up questions on this:

- How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)

- Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.


> How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)

I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off.

> Does Aurora sometimes reboot multiple times when doing updates?

I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.


Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).

The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.

Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.

Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).

Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.


It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.

But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".


I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.

"Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.

> So let’s say OpenAI cure cancer and put every cancer researcher out of work depriving them of intellectual satisfaction, this would also be a problem? It would certainly impact the field.

Would you expect Fields medalists to cure cancer if you moved them from the math department to a medical research lab? This is precisely the fallacy that the frontier labs are counting on to inflate their valuation as their IPO approaches. They want to use headline-grabbing problems in pure maths to make their models look "smart" in the public eye. But what does "smartness" in mathematics really mean in terms of economic value? It is not at all obvious whether success in abstract mathematics should translate to successes and, more importantly, profitability, in more grounded endeavors.

Look at OpenAI's job postings (https://openai.com/careers/search/). Those roles involve far more pedestrian yet profitable duties than research mathematics. So why isn't OpenAI automating them with their vaunted models? Success in one field, no matter how "difficult", does not predict results in another field.


> This is a demonstrable fact as no human has figured this out despite the problem being open for almost 100 years.

That's not true. Alpoge and Buckmaster's related LLM-assisted blowup result (https://news.ycombinator.com/item?id=49605915) utilized a strategy developed recently by Cordoba and Martinez-Zoroa.


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

Search: