I agree. I don't understand how people prefer buildroot. Buildroot feels like an adhoc system of glued together Makefiles, whereas yocto actually feels like it was built for purpose.
Yocto feels like a ball of mud duct taped together, but thankfully has good documentation. It reminds me of CMake. Buildroot is nice for relatively simple situations. Nixos is arguably better than both.
You don't _have_ to, I think the parent poster is just giving an example of how this can be used.
The "Zero Knowledge" part is that you can tell me "for this particular program code, I know an input that gives an output of 'foobar'" and I can be convinced that you're telling me the truth without seeing what that input actually is.
I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.
I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing.
I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created.
When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status.
It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.
Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.
Teams must advocate for projects, but, for individuals, one solution that I've seen help is that the week long oncall developer handles sprint interruptions, slack questions, and bugs. No sprint commitments. If something is not on fire, they get to work on whatever they think will add value at their discretion. New tooling, proof of concepts, pet-peeve bugs that can't get prioritized, etc.
After lots of stabilization work, devs looked forward to oncall.
> Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.
As an Engineering leader, I try my hardest to make sure this Slack exists for the exact reasons you listed.
I feel this. The zero-sum pendulum of time is a bitch.
I wonder, are you under 35? This story reminds me of my experience. When I was younger, all the problems could be solved - all at once. I'd throw time at just about everything - cleaner code, fewer bugs, features delivered.
Later, the scope of what I was working on grew. No amount of time could be thrown at all the problems - it was zero sum. I had mentors try to guide me, to focus on solving what you need to, to focus on areas of impact and let the other things slide. If you don't, then the areas of impact never get done.
On the other side of the coin, the really frustrating part - is the bullshit processes you speak of. Time is zero sum. Yet, here was the team wasting time on another status meeting and time estimation; not getting the things done. Small quick wins, which do have impact, are not small quick wins because - did you fill out the TPS report regarding user impact? Did that get approval and story pointing? Is it a strategic initiative? No, then why are you working on it? Those are unhealthy orgs. Places like that I think are filled with folks that can't do the job and ride the coat tails of those that get shit done. These are also places where people want to go, clock in, and just not think that hard about their job - just do it and get home to their families.
Though, I've come to also appreciate that mentality too. I've never been a true owner at any place I've worked at. I've cared, I've been tricked into caring - but the long hours only went to enriching the person that had 1M shares, while I had just 2000. They were an owner, I was pawn.
I've worked in mid-sized companies where my job wasn't just one thing, and where I was not owned by a project manager. Other concerns existed. Even back at the ancient bank I worked at, our implementation of ITIL recognised this, and put incident and problem managers on equal footing with project managers. If a frequent issue is caused by some underlying problem, that problem needs to be fixed. Working on it was absolutely legitimate. During sprint planning a team could take work from the new features like or the bugs pile without interference from a project manager. If they complained that you worked on a bug, you could lean on the problem manager to talk to the project manager. If the project manager's timelines drift, part of their job is to deal with that, inform stakeholders and extend the deadlines. If they continually fail to factor in the possibility of conflicting work then they suck at their job. If their boss gives them shit for a slipping deadline that was out of their control, then they also suck. In your example the company allocate 100% of your time to working on new features and none of it to maintaining the product or keeping customers happy. There's no point in putting a brand new engine into a rusty car with bald tyres. This a bad organisation.
> I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product.
Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?
I'm going to say it is efficiency and the ability to implement ideas well, even if they are stolen ideas, that account for more of the success for anything else.
I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.
> If you were on the free Hobby plan at the time that the paid Hobby plan became the default for new organizations, your plan is now called the Legacy Hobby plan. Your costs stay the same as they were, with no monthly subscription fee, and no included usage beyond the free resource allowances.
so i get to use the legacy hobby plan because i'm grandfathered in, nice. only use it for a hobby project with one instance anyways(see bio), if they really decide to start charging me i'll gladly leave.
Heya, we deprecated pretty loudly! We made a post on the community forum [0] and we sent an email to all active accounts saying the following:
> The first improvement we're excited to announce is that the $5 Hobby plan is no more. We're replacing it with a very simple Pay As You Go plan. On this plan there's no more upfront $5 charge and no minimum monthly commitment. You only pay for what you use. If you don't use anything for a given month you pay $0. You still need a credit card on file to prevent abuse. But your card is only charged if you use the service.
If anyone's ever wondering how carefully choreographed our HN presence is, please refer them directly to this subthread, which, for posterity's sake, I will note is occurring on the morning of July 4.
Sorry, didn’t intend for throwaway to come across as not standing behind the product.
I wrote the community forum announcement and was one of the people that worked on implementing our PAYG plan. I just wanted to clarify that we didn’t deprecate silently, so I quickly created an account to do so.
random side note, it would be nice if the region selector for regional pricing would display human readable region labels in addition to 3 letter acronyms.
Whoa, they did get rid of it. Not surprising in the least, but they definitely did it with a minimum of fanfare. When Heroku got rid of their free plans at least they were upfront and released a blog post about it. Maybe they did and I just didn't notice.
> I know developers like to put their head in sand and pretend to the contrary, but credentials do matter. Things like security or cloud certifications and security clearances
Interesting, I've interviewed with and for a number of tech companies and it's never come up. What companies are you seeing who are interested in certs?
In the past as a JavaScript developer they are happy if you are smart enough to spell your own name or color within the lines without eating the crayons.
This year though things have been far more competitive. I wasn’t getting interviews at all until I focused on a combination of my development experience, my TS, and my certs. Since then I have had many interviews and several competing offers. In one case I given an offer to write test automation in Java with 0 years experience writing Java at this big rocket company, I do have experience writing test automation utilities though. I have since taken a work from job on API architecture for this massive data enterprise.
Much like the infamous FTT token, just because it’s worth that much on paper doesn’t mean that is what you could sell it for today. I say this as a person with chunks of stock in a few private companies.
And obviously for the people impacted, it’s quite a loss to get all your money over a year after you tried to withdraw it, even if you do get it all.
In a slightly different universe, the literally criminal risk might have worked a little longer.
Then again, GenAI perhaps undermines the notion of NFTs and "digital art/assets as valuable fungible commodities." It was really wierd seeing Stable Diffusion take off as NFTs were collapsing... so maybe there is no universe where FTX fakes it until they make it.
Keep in mind that "NFTs representing digital art" are a subset of what NFTs are. GenAI might have impacted art tokens, but wouldn't affect NFTs as a whole.
That’s right, NFT’s are a tool for low talent charlatans to grift at scale off of laypeople by claiming they will make money buying them. The digital art was just one such con.
The concept of NFTs for art is pretty new. I first heard about the idea of NFTs in 2013 and that was using them for things like deeds to land and vehicles.
which is incredibly stupid because a nft is fundamentally incapable of solving these challenges (owning the nft means nothing if a court determines someone else owns the house)
... which remains a terrible idea, because what happens to your land or vehicle if you lose your keys / forget your pass phrase? Or if someone else phishes you?
The whole idea of GenAI is to make purely digital content "cheap."
And that's basically NFT's niche, as I understand it. Why bother commoditizing the digital space when (according to GenAI acolytes) digital scarcity is going to disappear anyway?
I dunno about NFTs representing real world assets either. It feels like the order is fundamentally lost once that jump to the real world made.
Digital scarcity is an artificial creation of copyright law, bought by people who had a vested interest in porting analog rules over to the new world after the infinitely error-free replicability of digital goods threatened their profit model. If generative AI puts them back in the same quandary, they will simply buy more laws and continue protecting their wealth.
Copyright law has the exact same purpose for digital goods as it did for physical books. Copying books has not really been hard since the 1450s or so. Copyright has always been about maintaining the value of books and other art works in the face of vastly cheaper copying.
The only important difference between physical copyright and digital copyright is the fact that you aren't allowed, in most jurisdictions, to sell on your legally obtained digital copy of something the same way you are for a physical copy. And even this is understandable.
The big problem with copyright is not the existence of it. It's the absurd terms it has gotten to. If copyright maxxed out at, say, 10 years, or even 20, we would live in a much better place than either today or even than a world with no copyright at all.
If I'm a creditor in FTX, it's a pretty big gamble, and I'm definitely not sure I'd be willing to settle for "sure, give me some shares in some AI company...". A significant chance that value craters, after all.
As long as you’re able to sell those shares immediately, a bunch of money loaded investors will be waiting to get your fraction of the AI pie from you.
> As long as you’re able to sell those shares immediately
You can't. Trades in even the most liquid private companies can still take weeks to close, if not longer. Add on the transfer restrictions that Anthropic almost certainly has, and you're going to be holding those shares for a long time.
I think that’s the most likely outcome: look for a buyer willing to take all the shares at market value, but also willing to offer shares to creditors willing to keep some Anthropic at a private valuation. Not sure if there’s a risk they’ll be more than a thousand people, triggering the need for an IPO — which presumably Anthropic would oppose.
It’s an interesting question. The shares are likely not transferrable without amending the LLC agreement or whatever. If you want in on Anthropic, though, and you know the FTX estate has to liquidate, then there’s a chance you can get to a good price; maybe less than $3B but probably not a ton, because lots of other people want in too.
On the other hand, the current investors probably won’t want to make an exception for FTX if they know it’s going to cause them to write down their stakes.
Lots of investors want in on Anthropic and OpenAI but can't. Getting access to shares to participate in this market (with market leaders) is not easy, especially not at scale. Amazon and Google were willing to pay an above-market premium to align strategically, but financial investors I can see do 80-90% of that valuation and be very happy.
They're buying it and holding it for the long run. Maybe it is as simple as letting them and other privileged parties buy more from FTX's stake and then redirecting the proceeds to each creditor.
Errors are composable so this isn't such a problem in practice. Most of the prod code I wrote would do something like this
use thiserror::Error;
#[derive(Error, Debug)]
enum Error {
#[error("Could not open given decomp file: {0}")]
FileOpen(#[from] std:io::Error),
#[error("Compressed read error: {0}")]
CompressedRead(#[from] gz::Error)
}
fn decomp(filename: &Path) -> Result<Vec<u8>, Error> {
let fd = File::open(filename)?; // File is automatically closed by its destructor.
let zd = GzDecoder::new(fd); // flate2::read::GzDecoder::new does not return an error.
let mut data = Vec::new(); // Rust makes the caller allocate the buffer for reads.
zd.read_to_end(&mut data)?;
Ok(data)
}
Huh, can you explain that a bit more for a rust noob like myself?
1. How does it know how to create your Error enum? I guess it's from the #[from]?
2. What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
3. How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
> How does it know how to create your Error enum? I guess it's from the #[from]? 2.
#[from] is just a convenience library feature, in reality it’s because of the From conversion trait which ? invokes on the way out. Essentially it calls ReturnType::from(ValueType) to bridge the two.
> What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
If there is no available conversion to the return error type, compilation fails.
> How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?
That is an option, although the slightly sad truth is libraries usually have a single big error type and every function returns that.
Convenient fine grained errors in rust remains unsolved, as far as I know. You can do it but it’s a lot of manual work.
reply