chaxor

However, I think there is no reason at all that a system that is decentralized is not far _far_ simpler to instantiate for a user (not to mention far more secure and private). Crypto gets a lot of hate on HN, but it seems that it is mostly due to people's dislike of anything dealing with 'currency' systems or financial that touch it. This is a despised opinion here, but I am still actually excited for crypto systems that solve real world problems like TLS certs, DNS, et al.

Iroh seems like a _fantastic_, phenomenal system to showcase this idea. It allows for a very fast decentralized web experience on modern cryptography such as Blake3, QUIC, and so on but doesn't really touch any financial stuff at all. Its simply a good system.

I hope we can slowly move to a system that uses the decntralized consensus algorithms created in the crypto space to remove the trust in (typically big, corporate, and likely backdoored) centralized entities that our system today _requires_ without any alternative.

While for most of my jobs I ended up being able to evade the use of HPC by simply being smarter and discovering better algorithms to process information, I recall like pyspark decently, but preferring the simplicity of ballista over pyspark due to the simpler installation of Rust over managing Java and JVM junk. The constant problems caused by anything using JVM backend and the environment config with it was terrible to add to a new system every time I ran a new program.

In this regard, ballista is a enormous improvement. Anything that is a one-line install via pip on any new system, runs local-first without any cloud or telemetry, and requires no change in code to run on a laptop vs HPC is the only option worth even beginning to look into and use.

More seriously, even 16GB was essentially the 'norm' in consumer PCs about 15 years ago.

Most developers work with a Unix mindset (do one thing well, with focus on simple and easily managed code), which tyically means telemetry is _wildly_ out of line (offers no real benefit for the basics while adding huge complexity), so privacy and security are naturally far better. Lynx like TUI browsers are a nice idea, but unfortunately sometimes an image is desired to be manually viewed, or javascript is required. It would be wonderful if javascript were simply dropped from most websites, but we don't live in that world, so we're stuck with the next best thing (disabling all js until explicitly allowed by the user).

These are the types of things people in software devs typically care about, which there are many in HN.

Servo is upcoming, but so far it is fantastic in comparison to any other browser out there.

I tend to focus on any software that does not require 12 teams of people 6 weeks to determine how to build a single binary because of the use of 20 different programming languages and mixing and matching of paradigms and solutions to subconponents. I very much appreciate simplicity and look for highly secure and private programs that highly discourage JavaScript from ever being run.

Servo is finally a breath of fresh air in that regard.

It would be nice to have a completely open source browser that can be built with a simple one liner from cargo. Having several thousands of eyes on the code daily to check for telemetry violations, privacy issues, security, and performance daily in mostly a single language, small, and well structured browser repo would be phenomenal compared to the disjoint jumbled messes we have today.

It was my understanding that Mastadon has _far less_ javascript than Twitter, not more.

The UI for mastadon always seemed far cleaner, more performant, and importantly - capable of actually loading, compared to twitter

Essentially, anytime something is shared from twitter I simply ignore it, because it may take a good 40 minutes to figure out the workaround to view it, compared to Mastadon which 'just works'.

I bought a macbook a while ago specifically because I can get it to last about 45-50 hours non-stop usage on one charge, so getting a system tailored for even better performance and a longer battery life (macbooks could probably double or triple battery life if they bulked up and stopped trying to be so petite) would be incredible.

>100 hour battery lifes should be very achiebable for developers, as limiting screen brightness and using only terminal with a black background can increase battery life _enormously_.

If one is very interested in security and privacy however, using VMs for isolation of different apps or services is important, so having an OS that helps that is useful. Bare arch _can_ do this, but requires quite a lot of script development.

Qubes seems to be the answer many grab for, though much is still written in C, which comes with all of the vulnerabilities mentioned constantly. So, something like https://diosix.org/ (a Rust-based hypervisor for Risc-V) is a great option to make a start towards decently secure system. Of course if your threat model includes state actors or something, you're SOL (change your perspective or what you're doing) since they always have an easy backdoor into any hardware, but sometimes things like diosix can protect against the constant script kiddies and other individual hackers.

A very minimal Rust-only browser with security and privacy in mind at every single step is completely missing from browsers today. Things like waterfox et al are enormous projects that take far too long for one person to audit the entire code base to ensure correctness. Something like the 'wireguard of browsers' in this regard is needed (single repo that one person can read over in a day and can be built with a single cargo build command). Even servo unfortunately falls just barely shy of this goal, but one can dream.

It probably depends on what "modern" means here. If updating from tons of COBOL to {Julia, Python, Rust, or some other well known language} with an update to an SQLite backend (or perhaps postgres is acceptable for very specific scenarios), that is likely a good choice due to being able to fix old cruft and add maintainability for the future. If it's a switch to some nosql database backend with everything switched to some cypher-based lang or anything that touches javascript in any way, it's probably a mistake.

As it has been for decades now, the 'Nan' type of answer in NLP is important, adds great capability, and is often glossed over.

I think your argument is about specific implementations of WM. While the argument of "I deal with X11-based WMs because it's fine when I don't care about security at all" may be valid in very narrow cases (such as air-gapped systems), the argument more generally is pretty weak.

Its not surpising that x11 based WMs, such as the almighty [awesomeWM](https://github.com/awesomeWM/awesome), have more features implemented than, for instance, [jay](https://github.com/mahkoh/jay) due to the enormous time it has had to develop (though I am _very_ excited to see `jay` develop more fully, and expect it to be well used by the more tech-savy devs).

However, some WMs in the Wayland space are doing quite well on that front. I recently had some substantial problems arise in my system which (surprisingly to me, but perhaps some are getting used to this) would have been prevented by using a memory safety language for my WM, so I have made the switch to (for better or worse) only ever consider Wayland+Rust WMs. In this space, [niri](https://github.com/YaLTeR/niri) is actually quite good, and to the point - it is developing correctly _and very quickly_. So, any issues on some WM not implementing some desired feature are quickly disappearing.

IIRC, all the major 'gateway' linux distros, such as Ubuntu or Fedora, are all on Wayland by default now - so I don't imagine x11 will stay relevant much longer.

Ai-folio or academic pages is basically my use case or target, but I want something with zero javascript, which tends to be a bit hard in todays age.

Only a few years more of my life lost to check all of the code of Linux and ensure I know what is running. I'm not bitter about and looking for better solutions to that at all.

The trick is getting everyone to switch over and ensure correct security and correctness for the newer software. A good example may be openssh. It is very well established, so many will use it - but it has had some issues over the years, and due to that, it is actually _very_ difficult now to know what the _correct_ way to configure it for the best, modern, performant, and _secure_ operation. There are hundreds of different options for it, almost all of them existing for 'legacy reasons' (in other words no one should ever use in any circumstance that requires any security).

Then along comes things like mosh or dropbear, which seem like they _may_ improve security, but still basically do the same thing as openssh, so it is unclear if they have a the same security problems and simply don't get reported due to lower use, or if they aren't vulnerable.

While simultaneously, things like quicssh-rs rewrite the idea but completely differently, such that it is likely far, far more secure (and importantly simpler!), but getting more eyes on it for security is still important.

So effectively, having things like Linux move to Rust (but as the proper foundation rather than some new and untrusted entity) can be great when considering any 'rewrite' of software, not only for removing the cruft that we now know shouldn't be used due to having better solutions (enforce using only best and modern crypto or filesystems, and so on), but also to remodel the software to be more simple, cleaner, concise, and correct.

My main point was that there is a lot of noise in scientific journals that are caused from pressures in academia that are requirements if publishing. If these are removed, then the quality of work published increases and quantity decreased.

There are other places to post work that is derivative and non-novel like blogs. The field of biology has an immense amount of work that is mostly observational without strong conclusions or predictivity. A tabulation of observation should definitely be put out by a lab, and it should be much sooner with far less pressures than today, such as the typical dance of putting the data in during publication. The SRA is one example of a place to share data. If the typical way to work was put all data immediately onto a public repo, sometimes comment on it in ways that have been seen before on blogs and other classes below scientific journals, and then if something truly substantial comes out of it (a novel model that is analytical and highly predictive of cell behavior in all situations for example) then publish.

It could alleviate the noise from the signal. LLMs is one case where the noise is very strong in that many papers are simply 'we fine tuned an llm'.

The "will it work in 10 years?" just swayed _immensely_ in Typst's favor.

Odd statement. I don't really know what you mean by that. Perhaps 'math _works_, code should too' ?

I would definitely agree that it _should_ work.

I'm of the belief that no one should _have to_ publish (e.g. to graduate, get promotions, etc) in academia, and that publications should only occur if they're believed to be near Novel prize worthy, and fully reproducible by code with packaging that should last and work in 10 years, from data archives that will exist in 10 years.

But it seems I have been outvoted by the administration in academia.

Hence, we get this "ai that doesn't run" phenomenon

_No_ level of lead is safe and_no_ level of lead is acceptable. That's a statement from CDC, WHO, or any other 3 letter agency you could ask.

Why is it still "used". Often, the difference is in percentage of lead in products when it's intentional vs not (probably obvious). The part that may be less known is how difficult it is to ensure that steel or other metals don't have <0.001% lead still in them, and even that is far, far too high (see original statement on lead safety level).

Working in characterization of materials _can be_ difficult. I have had 3 different pieces of equipment give 10% X, 50%X, and 80% X all for exactly the same batch of the same material.

However, lead is far more established in it's characterization in metals, so _given enough care and money_ these problems don't really occur.

This company, and many others, aren't going to check - that's the government's job to worry about the safety and health of the public, and protect them if a company makes an unknowingly harmful product. The government meanwhile does not have the funding, personnel, or time to tackle such a monumental task. This is why it takes so long to find bad products like this - it's typically on the shoulders of curious individuals.

To recap, this _should be_ a solved issue (also lead needs to come out of GA, as it has been shown to be possible for decades, and actually _harms_ the engines of small planes), but as it often is, harming people to save money spells success in our world.

So there's that.

There is a decent amount of evidence around this, though of course there are some assumptions made that are difficult to show directly (such as RF causing changes over intermittent use for years on living tissue from direct observations of hypothesized mechanisms, either RNA, protein or otherwise.). The typical argument is 'it is significantly altered in individuals that use devices more, has a "dose/time-dependent" effect, and convincing ipsilateral patterning', paired with 'there are changes in cell behavior under RF in vitro'. So a leap made is sticking the two together, but it's not a completely crazy one.

Is there a better alternative like Alpine but with glibc that isn't Debian?

The free TTS options aren't great still, and "just the abstract" is not the problem. I did full articles, and the hard...er (it was a few hours) part was extracting out the relevant sections of full papers without the 'junk' info (page numbers, superscript citations, 7 pages of authors in any cern paper, etc.

So you get something, but it's often not good.