MurphyA/hacker-news huggingface dataset:
by princevegeta89 | 2025-05-13 02:44:34+00:00
I used Ruby a lot a long time ago and built medium to large scale enterprise apps on the Rails framework before I moved on to other projects involving Golang and Elixir. Somehow I had more fun and more safety working with Elixir, which was only just getting started as a brand new language trying to establish itself.

It was only after working with Go that I realized how much compile-time safety and performance I was missing out on with Ruby.There's no doubt I would use Ruby today again, but I can't imagine going further beyond simple scripts and workflows. I have recently tried building a very small website with Rails, and I was somewhat surprised the framework did not mature all that much, and type safety and IDE support still seem to be iffy. There is so much unwanted magic that I still see with Ruby on Rails in general. I was looking up to Crystal to address some of the issues I described above, but unfortunately it just remained as a less mature language. Elixir was great, but with the experience I have had, I will actually drop heading into the functional programming world. That leaves me with only one choice, which is Golang. I am not a fan of everything it has, but it is fairly easy for my fellow engineers to pick up, and the IDE support has been nothing short of fantastic.

This is really really a big stretch, but I have always been hopeful towards looking for a TypeScript sort of compile-time layer for Ruby. It may probably never happen though, sadly.
by brucehoult | 2025-05-13 02:44:39+00:00
> RISC-V is heralded by many as “the next big thing” since it is an open and royalty-free ISA, but it has been a sort of red-haired stepchild for a long time, in the sense that it has always been much slower and gotten less overall industry support than ARM.

I really don't understand why people say things like this. You don't see every review of an Arm SBC lamenting how far behind Intel/AMD Arm is.

ARM has been around for decades, the ARMv8.0-A ISA implemented by the Cortex-A72 in the Pi 4 was published in 2011 and the ARMv8.2-A ISA used in the Cortex-A55 and A76 (RK3588) was published in 2017.

The Pi 4 appeared in 2019 8 years after its ISA was published, the RK3588 machines started to appear in 2022 (and the Pi 5 in 2023) which is 5-6 years after the ARMv8.2-A ISA was published.

Nothing wrong with that ... it is typical.

This Orange Pi RV2 uses the RVA22+V ISA which was ratified/published in March 2023, just two years ago. Even the original RISC-V specification, RV64GC (now called RVA20) was published in mid 2019, less than six years ago.

Arm has decades of head start on RISC-V, RISC-V specifications are currently around six years behind equivalent Arm specifications -- even a little less now, as RVA23 was published in October 2024 just 3 1/2 years after ARMv9 which is it essentially equivalent to.

And, if anything, RISC-V boards are coming out sooner after the relevant spec is published than for Arm boards. Especially when you consider that the Banana Pi BPI-F3, with essentially the same SoC as the Orange Pi RV2, has been out for a year.

We've only seen the first ARMv9 SBC in the last two months.

> I would ordinarily use Armbian if this were an ARM board, but that was obviously not an option here.

Armbian is available for the Banana Pi BPI-F3, which uses the same SoC. It'll probably be along for the RV2 shortly.

https://www.armbian.com/download/?arch=riscv64

> pegs the RV2 at about half the performance of a Raspberry Pi 4

I don't know why people compare RISC-V boards like this to the OoO Pi 4. An A53 or A55 board such as the Pi 3 or Odroid C2 or C4 are a much more appropriate comparison as they have very similar µarch. Or the various RK3288, RK3566 or Allwinner A523 etc boards.
by 0xbadcafebee | 2025-05-13 02:45:55+00:00
So for ya'll who haven't been involved with DoD/secret/etc cloud projects, there's a bunch of jargon to learn, but suffice to say there's a lot legally-required standards that define the right way to run secure government IT. It's normal good practice, but cranked up, standardized, and verified.

There is a problem though. With so many companies moving projects to the cloud, the government would need to take time to verify everyone is as secure as they're supposed to be. But that would require a huge number of new employees (thus $$$) and it would still take a lot of time. So how does the government make sure they're all secure before they send them secret data? Here's a tip:

> The concept emphasizes security over compliance

Huh? How can you have security without compliance?

Afaik, "compliance" means "we make sure they're as secure as they say they are". And how do they do that? For the past few years at least, it's involved a process called self-attestation. The company fills out a bunch of forms, and sends them to the government, saying "we promise we are doing all these things like you told us to". And then the government... takes them at their word. As you can imagine, with millions/billions of dollars to earn, companies might be incentivized to fudge it a bit. And fudge it they do... (not just FedRAMP, but NIST 800-54, 800-171, CMMC v1/2/3, etc etc).

Now, with so many companies and use cases, there are obviously some things that won't apply to some companies, so it would be nice if they could avoid that red tape. With the old processes, if you were actually doing things the right way, it could take a company between 6 months and 1 year to set everything up securely / the way the govt wants it. There's a whole cottage industry dedicated to helping companies understand how the fuck to follow these regulations. But since that's expensive and time consuming.... a lot of companies just fudge it, or call a friend who knows a friend who knows a General.

That was the state of things before this "20x" version of FedRAMP was released. Personally I was not thrilled by the state of things before, but this seems to be both accelerating the process, and providing less oversight. Not great for the military, not great for national security, but really great for "industry" and any military branch getting a contract faster and cheaper than otherwise.

(disclaimer: i'm a noob in this area, but I dipped my toes in last year, and "shitshow" would be one way to put it...)
by schultzer | 2025-05-13 02:46:09+00:00
Elixir compiler is written in Erlang, Erlang can produce very efficient code, the new json library can beat c libraries at decoding / encoding. And you get this with a strongly typed dynamic language, which is a distributed language. It’s really hard to beat the BEAM, if only we had better number crunching, but in so cases you can always write a nif.
by trollbridge | 2025-05-13 02:46:30+00:00
This was around 8 years ago, but there was no MDM installed on our cell phones, regardless of if BYOB or company paid for device.

The only restriction was if you went to China, you took a burner phone (one of the old company phones, usually) and weren’t supposed to ever use it again once you left. I think they just sold them to a liquidator.
by pveierland | 2025-05-13 02:46:49+00:00
Yes, Nix does not provide you a guarantee that there are no impurities in builds, which the extensional model specifically caters to, and where the intentional model improves upon this by providing a system bases on content hashes instead of input hashes.

However, Nix specially attempts to facilitate a pure software distribution model, which is why it does everything it does, e.g. forcing all input files to be copied to the store and providing mechanisms such as the pure evaluation mode which restricts access to the current system and time information. Yes, there are other ways to introduce impurities, but Nix tries in many ways to systematically remove these sources to increase the purity of the deployment process.

If the entire process of building an artifact is pure, then the artifact would be entirely reproducible, given that you have access to the same inputs. Yes, there are many ways to introduce impurity, however claiming that Nix as a purely functional software distribution model, where the central point is to achieve purity, is fully orthogonal to reproducible builds, seems incorrect.
by AdieuToLogic | 2025-05-13 02:47:15+00:00
I agree with your point about reasoning when employing Functional Programming (FP).

However, I very much disagree with Graham's 2004 assertion[0]:

It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

It does not require "a lot of work to learn a new programming language" once a person has fluency with at least one. Actually, the difficulty of learning a new programming language is inversely proportional to how many programming languages the person has already learned. Especially if a new programming language is in the same paradigm category as those already known (Procedural, OOP, FP, etc.).

I was a professional software engineer in 2004, when the Graham post was written. To say, "people don't learn Python because it will get them a job ..." was bullshit then just as it is now. The remainder of the quoted sentence is unfounded extrapolation and has the value of same.

0 - https://www.paulgraham.com/pypar.html
by sinuhe69 | 2025-05-13 02:47:25+00:00
What about the famous breakfast? One prevalent theory among nutritionists is that the breakfast has huge influence on the insulin responses during the day: a low carb/no sugar, high protein and fat breakfast will not spike your blood glucose level and therefore will lead to a more moderate response to meal intake during the day as opposite to a high carb breakfast. I think the study should control this variable as well.
by mindslight | 2025-05-13 02:50:12+00:00
The political platform for rebuilding our country after the destructionists are deposed (which will happen sooner or later) needs to include scrutinizing every single one of these sales and/or long term contracts, and outright invalidating many of them as the fraudulent conveyances that they are. No just accepting the nonsense of "oh that's private property now, nothing can be done". If the precedent discourages "investment" (aka looting) of government institutions in the future, that's a good thing.
by bandrami | 2025-05-13 02:50:24+00:00
I mean, people released a billion clones of flappy bird before AI so I don't see why they would stop? The dominant mobile game genre seems to be "line up three of the same thing and get a prize which will make you want to buy a better prize in our online store"; I don't see a flood of new entrants to this space.

Do LLMs just not work for mobile development? What about native? Why is the only thing I'm actually seeing produced increasingly byzantine tooling for AI itself?
by rich_sasha | 2025-05-13 02:51:28+00:00
To add to the list, this article [1] alleges that a number of Afghan special forces were refused a UK visa upon withdrawal, so they couldn't testify in the UK against the UK special forces. Then when the Taliban took over, the predictable happened. Pretty shocking.

[1] https://www.bbc.com/news/articles/cp3q5xl9wqwo
by fallingknife | 2025-05-13 02:52:17+00:00
Same energy to enter the orbit, but the kinetic energy per unit mass should be a whole lot higher at Venus than Earth, so each of your shots count for a lot more. But yeah, the main advantage is the moon. And you wouldn't launch things from the moon. You would launch pieces of the moon from mass drivers.

The situation I replied to assumed they were both inhabitable planets which I assume means Earth like atmosphere on Venus. The thick atmosphere complicates things, but I don't think you actually have to hit the ground. Tunguska didn't even get near the ground and it still leveled 1000 km^2. Also if Venus has the atmosphere there's no point of a war since there's no benefit to conquest in either direction.
Show HN: RevGrow – AI Revenue Growth Strategies No Manual Analysis
by Bkimmy16 | 2025-05-13 02:52:40+00:00
RevGrow AI is a revenue intelligence platform designed for startups and growing businesses. It solves the problem of developing effective revenue growth strategies, which is often difficult due to the challenge of manually analyzing complex data. Many businesses lose revenue by not effectively understanding how outside factors like weather, competitor activity, and social trends impact their sales. RevGrow AI uniquely addresses this by combining diverse external data, specific to your business, with your internal metrics using AI analysis. This reveals specific revenue opportunities being missed and identifies areas where money is leaking. The platform then provides quantified strategies and actionable steps to capture that revenue or fix those leaks.
by dendrite9 | 2025-05-13 02:53:35+00:00
There's even a rear steering cargo trike company in Denmark. It's weird but I had an explanation that it was meant for low speed and maneuverability with cargo rather than as an exercise machine or high speed transportation.

I've ridden a few trikes like you'd use for a small food stand and they aren't so bad to drive around. Would I take one mountain biking or on a hill climb? No, but that's beside the point. I also don't use my phone for all my CAD work.
by dangus | 2025-05-13 02:54:02+00:00
I was actually surprised that this post wasn’t going to be about software trends. I think there could be more attention paid to software business concepts that are essentially throw away pump and dump schemes. E.g., all the VSCode forks for AI coding that are already collapsing away/being acquired and enshittified.

But back to the hardware, the hardware disposability isn’t a new phenomenon but it’s still a big problem and a catchy phrase to help bring more attention to the throw away nature of it would be a good start.

What really needs to be implemented is some kind of regulation on product features like built-in wear items and irreplaceable batteries, as well as software deprecation.

There are a number of ways it could be implemented that could effectively discourage these practices, just some possible ideas:

I think a recycling program similar to many states’ recycling deposits could work really well. Each product gets a recycling serial number, customers return them to a collection center and get paid a certain percentage of the original sale price/MSRP, perhaps that percent would go down the older the item is. The refund is paid for by the original manufacturer.
by Barrin92 | 2025-05-13 02:55:11+00:00
>That's the industry.

I think this is complete nonsense to be honest. If you're 42 with 20 years of experience you can walk into any random municipal office in a reasonably large town and find a software or at least IT admin job that people will throw at you, because chances are the youngest person there is 55.

The only ageist part of the software industry is the whole web and startup sector, your average post office, hospital, government and education software job is full of middle aged people. If you're unemployed just take a job there
by nmgycombinator | 2025-05-13 02:55:33+00:00
As someone who dove deep into keychain items for a previous write-up, I believe you are misunderstanding this situation. As far as I understand it, many keychain items can be stored in your iCloud keychain. However, your local machine can have its own keychain that's different than the iCloud keychain, with items that are not sent to iCloud.

And besides all that, to my knowledge your local machine password (the password you use to login) isn't stored in a keychain item, so there's no way it could make itself into the iCloud keychain, or your local keychain.

You may be mistaking some explanations. Your computer password is used to unlock your local keychain, but it itself is not stored in your keychain. Your local keychain is also not your iCloud keychain, it's not stored in iCloud.

Again, I'm not an Apple developer, so there may be stuff I don't know, but I am a developer in general and I have researched this. The above is my current understanding.
by AStonesThrow | 2025-05-13 02:55:55+00:00
I wouldn't say that Uber or Lyft (or other NEMT rideshares) ever scammed me, but I've had enough shitty experiences and felt burned enough times that their reputation is on-par with classical taxi services IMHO.

On the other hand, Waymo has never scammed me; I've never had a conflict with a shitty Waymo driver; and in fact I'm rather happy to participate in their testing phase and give generous feedback about minor things that could be better after each trip.
by protocolture | 2025-05-13 02:56:28+00:00
Some kind of demand reduction.

It could be the case that we finally hit a sold wall in CPU progress, cloud providers demand something they dont have to replace every few years, and the result is some kind of everlasting gobstopper CPU.

Then as failures fall off, so does demand, and then follows production.

A pretty large drop in global population might see the same result. Labor needs to be apportioned to basic needs before manufacturing.
by musicale | 2025-05-13 02:57:52+00:00
> And more fundamentally, there’s no good argument for humans to leave Earth in the first place

Said all the joyless, unimaginative naysayers in 1969.

There are lots of good arguments for going back to sleep, and forgetting about doing anything interesting or adventurous.

Turns out that going into space is pretty cool; it would be sad to let robots have all the fun.
by pornel | 2025-05-13 02:58:51+00:00
My non-techie relatives can't tell the difference between the local device password/passphrase and the iCloud/Apple ID password, so they'll enter them all until something works (I don't blame them, the UIs for these are unclear and inconsistent).

Apple used to make fun of Vista's UAC, but they've ended up with the same patchwork of sudden prompts, and even weaker UI.
by chrismorgan | 2025-05-13 02:59:20+00:00
> <meta charSet="utf-8"/>

Ah yes, Next.js, still producing stupid bad HTML more than six years after it was reported.

So, you pay over 200 kB of JavaScript just for the “in about 12 hours” text to be recomputed once a second. As far as I can see, that’s the only dynamic behaviour.

For some reason unclear to me I went ahead and made a more sensible version (with dead code stripped and about two tiny material changes in CSS or text, see if you can spot them), and, minified, it’s under 1350 bytes with everything but the favicon inline. In other words, more than a kilobyte smaller than the original markup, despite embedding the functionality of an extra 213 kB of JavaScript and CSS.

<!DOCTYPE html><meta charset=utf-8><meta name=viewport content="width=device-width"><title>Days Since Last JavaScript Framework</title><meta name=description content="Get the always up to date information about how many days have passed since a JavaScript framework has been published"><link rel=icon href=/favicon.png><style>body,html{font-family:sans-serif;margin:0;overflow:hidden}body{background-color:#fff}main{height:100vh;display:flex;justify-content:center}strong{font-size:20em;align-self:center}strong::selection{background:#000;color:#fff}.ribbon{background:#000;right:0;top:0}aside{padding:.2em .5em;color:#fff;position:absolute}.contact{font-size:.75em;background:#898989;bottom:0;left:0}.contact a{color:#00008b}</style><main><strong>0</strong></main><aside class=ribbon><b>updated daily!</b><br>next update in about 2 hours</aside><aside class=contact>if you spot an unlikely mistake on this website, get in touch:<a href=mailto:javascriptisa@veryfast.biz>javascriptisa@veryfast.biz</a></aside><script>function r(){var n=Date.now(),m=Math.round((Date.UTC(n.getUTCFullYear(),n.getUTCMonth(),n.getUTCDate()+1)-n)/60000);document.querySelector(".ribbon").lastChild.value="next update in "+m==0?"less than a minute":m==1?"1 minute":m<45?m+" minutes":m<90?"about 1 hour":"about "+Math.round(m/60)+" hours"}setInterval(r,1000);r()</script>

(Completely untested, not even run once.)
by andygrove | 2025-05-13 03:00:21+00:00
Congrats on the launch!

I contributed to the NVIDIA Spark RAPIDS project for ~4 years and for the past year have been contributing to DataFusion Comet, so I have some experience in Spark acceleration and I have some questions!

1. Given the momentum behind the existing OSS Spark accelerators (Spark RAPIDS, Gluten + Velox, DataFusion Comet), have you considered collaborating with and/or extending these projects? All of them are multi-year efforts with dedicated teams. Both Spark RAPIDS and Gluten + Velox are leveraging GPUs already.

2. You mentioned that "We're fully compatible with Spark SQL (and Spark)." and that is very impressive if true. None of the existing accelerators claim this. Spark compatibility is notoriously difficult with Spark accelerators built with non-JVM languages and alternate hardware architectures. You have to deal with different floating-point implementations and regex engines, for example.

Also, Spark has some pretty quirky behavior. Do you match Spark when casting the string "T2" to a timestamp, for example? Spark compatibility has been pretty much the bulk of the work in my experience so far.

Providing acceleration at the same time as guaranteeing the same behavior as Spark is difficult and the existing accelerators provide many configuration options to allow users to choose between performance and compatibility. I'm curious to hear your take on this topic and where your focus is on performance vs compatibility.
by alephnerd | 2025-05-13 03:00:45+00:00
> It’s mostly an easy button for procurement officers

I know. I have never had an issue with FedRAMP as a single marketplace. The issue has always been arbitrary compliance requirements

> Startups are always problematic for government procurement

Absolutely, and ensuring that they are within a verified marketplace such as that which FedRAMP intended to make is good.

The issue is the upfront cost to become FedRAMP compliant is so high, that most vendors do not even try until extremely late in their lifecycle.

Furthermore, a lack of vendors does lead to extremely suboptimal pricing. There is some cost to recoup from going through FedRAMP compliance hurdles, but a lot of it is also because once you are FedRAMP compliant, depending on the tooling, you have a captive market with maybe 1 or 2 competitors.

> Startups are always problematic for government procurement, and unless you play in a space that is setup to handle small vendors, your business is going through partners anyway

I'm not talking about SIs or MSSPs. I'm talking about specific FedRAMP compliance partners. They provide no value except checkboxing, but all of vendors need to partner with them.
by kaydub | 2025-05-13 03:02:49+00:00
Your example doesn't give details so it doesn't mean much.

First FedRAMP high is extremely strict. Most ATOs are NOT for FedRAMP high. Most people are good with a FedRAMP moderate.

Also, this doesn't mean the security controls are what stopped those other environments from being hacked. The other systems are just separate, that's why they weren't hacked with everything else.

Overall I think FedRAMP is good, because it at least gets somewhat of a baseline. But the other guy was pretty spot on. The auditors generally have no idea what they're looking at, there are a lot of security controls that don't make sense under many contexts and it is mostly a dog and pony show.

And really, it's not like these departments didn't have some type of due diligence to acquiring software, FedRAMP just makes it standardized and allows departments/agencies to piggyback off of other department/agency's due diligence.
by behindsight | 2025-05-13 03:02:53+00:00
From what I have gathered their main differentiator is taking the approach of assigning each discrete data point its own "entity" definition that is independent but can be extended for each data provider.

So since its all represented by entities, you could treat them like any other vectorised data in your vector data store and use vector search.

It's a nice technique, but probably tricky if they ever venture into encapsulating endpoints in realtime for rapidly changing b2c applications (ratelimits/cronjob latency)