I wrote some code with an IMAP lib. Wasn't too happy with out of the box things.
The smaller Deepseek models are most interesting for self hosting LLM's at the moment. Impressive! Many other ML Things need a lot less compute, though. Like facial recognition, spam filtering, etc.
awesome! how do you do email delivery? i still have to route things through an external service to get that to really work. oh yeah, i gave my son access and he hosts Rust and Minecraft servers.
i'm looking into doing security cam + AI. just canceled my Nest subscription.
The standup questions are awkward motivation killers. The people that look good in those meetings are usually just pandering. I'm convinced standups have stuck around because they make managers feel like they're adding value. If people are waiting until the next workday to be unblocked your team is moving too slowly.
On the flip side having the team chat regularly is a value add. Maybe you can talk about upcoming product things, ideas people have, the market in general, and any other thoughts people have top of mind. But forcing everyone to talk about what they're working on is counter productive. Everyone on the team knows if they want to know. If there isn't team visibility to what everyone is working on then something else is broken.
> If people are waiting until the next workday to be unblocked your team is moving too slowly.
Nobody said anything about waiting. Getting blocked can come up after yesterday's standup and still be an issue lesss than 24 hours later despite working on it.
> If there isn't team visibility to what everyone is working on then something else is broken.
Some people don't claim/update their tickets. Most people don't update their tickets with progress every day. Most people don't push WIP branches (and if they did, who has the time to look thru the entire team's WIP code?). Teammates on the ground are interested in what, specifically, their peers are working on and thinking about overlap/potential conflicts on the ground.
It seems to me that this is the risk you take when you create an unofficial add-on to any product.
I've helped reverse engineer vehicle ECU's to reprogram the fuel injection, turbo pressure, and spark timing systems. But, we wouldn't have expected the manufacturer to do anything except officially discourage the use of the aftermarket tools. That is the name of the game with unofficial add-ons with access to sensitive control systems.
Disclaimer: I did work for a Middleby subsidiary at the time but I don't know anything that isn't public about this situation. We were all very separate companies.
I guess the difference here is that there's 3 separate parties: McDonalds corporate, Taylor (makes the ice cream machines), and the franchisee. McDonalds requires the franchisee to buy a specific machine from Taylor (or a dramatically more $$ one from an Italian company IIRC), and places other requirements on the franchisee, but is it legal to interfere in the relationship between the franchisee and Taylor?
>legal to interfere in the relationship between the franchisee and Taylor?
I think the term is "tortious interference" but it is notoriously very difficult to have upheld in court. You can obviously compete but you can't deliberately undermine a contract with a competitor. IANAL, but from my reading of the article, that would rely on how substantive the safety claims that McD made are in disincentivizing the use of the 3rd party equipment. (not to mention they party wasn't explicitly named in those safety communications)
Funny that this is the opinion for this product, but mere mention of this concept for Beeper accessing Apple as an add-on product is thought of in a different manner. Because it's a physical product? Because it's not Apple?
Because people commenting on HN are not a hivemind. Some people think this some people think that and there is no guarantee or requirement that these independent thoughts from independent people are consistent.
There shouldn't even be an assumption that two people's definition of consistent lines up. Just because you can draw an equivalence between Taylor and Apple, doesn't mean that other people will or should.
It doesn't sound like the Kytch device was claimed to cause any kind of contamination, it just exposed diagnostic data? To me hacked ECUs seem much more likely to pose a danger to human health - but that's because bad drivers kill and injure a lot of people (maybe people who have done Level 3 tunes are all excellent and responsible drivers... maybe...)
>It doesn't sound like the Kytch device was claimed to cause any kind of contamination, it just exposed diagnostic data?
That's what the article says, but I vaguely remember that there were mentions of overriding the machine's safety interlocks. I searched around and sure enough, I found this:
>The Kytch, based on a Raspberry Pi, offered McDonald’s franchisees insight into both their machines’ operation and failures. It could also override locks that prevent the machines from working due to non-critical errors.
As for what the device does today, I'm not so sure. Maybe they realized that overriding locks presents a safety hazard and removed that feature. Maybe they kept it in but decided not to loudly advertise it because it'd make them look bad. Who knows.
This class of locks sounds a lot like the intro to a video game that says "press start to continue". Imagine your TV is broken so only displays the top half of the image. Are you overriding a lock when you press start, even though you can't see the message? Can I sell you a device that detects the top of the video game and flashes on its own screen "press start to continue"? Absolutely. That is all that's going on here and should be 100% legal.
Reading the lawsuit, though, I'm getting the impression that the safety interlocks on the machine are software-based, not hardware-based. That is, the lock says "door closed" or "door open", and the microcontroller refuses to do anything in the "door open" state. This is in contrast to a hardware lock, where the door closing closes a switch that AC power comes in through. Door open, no power, and completely failsafe.
In the case of software locks, I am sure that monitoring apparatus can break the software interlocks accidentally. I used to work for an ISP and wrote a program that SSH'd to each of our OLTs, and downloaded a ton of data about each customer and sync'd it into our database. (No API except SSH-ing in and typing commands, of course.) This totally broke them after a period of time. One Saturday morning I got a frantic Slack from the CEO "shut it off! all of our OLTs are dead!". (As an aside, I had a slack command to kill the monitoring jobs for exactly this reason... we all thought it was pretty hacky.) After debugging this with the vendor, it essentially turns out that reading data takes a lock, and the watchdog also tries to take that lock, and reboots if it can't within some ridiculous timeframe. (It was actually a little more complex than this, involving two redundant CPUs inside the device going out of sync after not being able to read the other's state for too long, but in the end, it's the watchdog that gets you. Their locks were also implemented wrong; "try to acquire it now, go to sleep for a long time if it fails", rather than being woken up when the lock is unlocked. That's what killed us, we did a LOT of reads, and were probably reading at the exact instant that this thing wanted to do its read to keep the system from rebooting.)
So anyway, in the case of the ice cream machine, this sort of bug is possible. The diagnostic tool is reading the internal state, the "transition to next phase" code runs, fails to get the lock on the door interlock state variable, incorrectly assumes "it's probably locked", and turns on the spinning ice cream mixer of death while someone's hand is elbow-deep in melted ice cream. At the end of the day, software interlocks are evil and have literally killed people before (see Therac-25), and the manufacturer of this machine probably doesn't want liability for bad code they've written. The monitoring device increases the chance of liability, so they want it dead.
I see their perspective, of course, but I still think that "that's too bad" is a fine response to their legal team.
Unity's just outgrowing the early adopters. The starving indies will move on to the next up and coming engine. Professionals will continue using Unity (and UE, which also charges royalties) because of the breadth and depth of the toolsets.
I first used Unity when their WebGL system was in private beta. IIRC they tried charging royalties early on but then reverted that for marketshare, but I don't have time to look it up. In any case the royalties aren't burdensome at that scale. I don't think it'll affect much. Vocal minority, yada yada. Maybe it'll even get them to profitability next year!
I've worked in game development for a long time, including a couple of games with over 100 million installs. Professional game studios making mobile free2play games, which is Unity's main moat, are VERY uneasy right now. For many games, the install tax would push them into unprofitability. Especially in hypercasual, where an average user may have LTV of a few cents total. These are billion dollar companies, and they have the resources to build their own engines, they just didn't have a real reason until now.
I'll have to try this! I have reflux or heartburn daily if I don't do things right. A few things help me.
1) Don't have an empty stomach. My stomach goes crazy.
2) Don't overeat. Large portions cause it nearly every time.
3) Don't eat anything within 2 hours of bed time.
So, basically, if I eat small meals often I am usually fine. And then there are trigger foods like too much coffee and alcohol and red sauces, and garlic and other things that cause indigestion.
I promise you, I had all this. If you try these supplements I mentioned you will never think about it again. The downside is you end up putting on some weight whilst you get over the fun of being able to eat whatever you want again :)
This isn’t an example of shooting the messenger because you dislike the message. The SF Chronicle just has a track record of anti SF bias, then turning around and complaining about the effects of their own reporting https://www.sfchronicle.com/projects/2023/sf-downtown-doom-l...
It’s sadly not a trustworthy source on these matters
React Native. TypeScript. NestJS backend, NextJS frontend. The ability to easily share code across the full stack is underrated. Of course you need someone that thinks at that high level building it.
On the opposite, I find that sharing code across full stack is becoming overrated. The reason I'm saying this is because that often leads to some very messy dependencies, and maintaining that codebase can become really difficult if you're not very careful.
Additionally, I found that in some teams, people would use some backend code on the frontend, resulting in some security vulnerabilities (server-side logic running on FE instead of BE). Instead, now that we have backend (Go) & frontend (TS) teams at my work, both teams consider the best practices for each environment with more focus. You could say that the same people do that with the same stack, but in my experience, if you allow people to put more focus on the one component they're building, they'll just build it better than when they have a plethora of other dependencies to consider.
The main problem could be talent, as if you have specialised people, you always have to hire for both of these positions (or train your people in either direction internally). But I honestly never experienced a shortage of people. It's more of a problem if you have a shortage of money, at which point, you should just use whatever you can build with the quickest to keep your business afloat.
I made Tamagui (with much effort) to solve this, which has probably the best setup out there at the moment for sharing your UI code on the frontend: https://tamagui.dev
For backend we're working on a starter kit that puts together all the pieces (there are a lot!) that's days from release, if you reach out on the Discord I can help get you on as a beta tester. It uses Supabase for data and auth, which seems to give the best overall package for data and auth.
For state depends entirely on the complexity of app. For simple apps you can get away with just something like React Query and Reacts useState, for more complex one of Daishi's state management libraries (everyone has their different preference, I love the black sheep Valtio), or the new kid on the block Legend State looks interesting.
The biggest part is getting a monorepo set up properly with shared code. Again the Tamagui starter repo `npm create tamagui` has this set up and its a whole ton of work saved in terms of getting that right.
FYI, the Silkscreen font on the website is completely illegible at smaller sizes like in the menus. Looks like a rendering glitch. Might want to choose something a little more legible.
Are you using a very dense resolution? I've turned off anti-aliasing, but if you scale your monitor to be more dense than natural resolutions it will appear quite odd. At "normal" resolutions it looks fine. I could turn aliasing back on at the cost of a bit of visual niceness for most.
Yeah, probably. I’m not sure exactly what the pixel density is, but it’s 1440 vertical pixels. Maybe try a resolution media query to toggle the antialiasing?
Types (interface contracts) are already easily sharable with an IDL and code generation. There's no need to stick to a common programming language to share types.
I'm highly skeptical of code sharing for other scenarios, and rarely (never) have seen the effort worth the payoff.
See my other comment above, but I was able to share basically everything that was not UI code. Types, request hooks, utils, configs/constants. Probably about 60% of the app, and you wouldn’t want to share UI code anyway because web and Native are so different.
The biggest confidence boost as a new programmer was the first time I wrote some software on my own, other people used it, it worked, and they liked it. This happened within about a year of starting out. I suggest everyone try to build products and give them to people. Nothing more validating to me than building stuff people want.
Come work with a couple YC alum to build the next great finance platform that doesn't take itself too seriously. Our top priority hire right now is a Product Designer. Do you like /r/wallstreetbets? Then you'll love working with us.
The smaller Deepseek models are most interesting for self hosting LLM's at the moment. Impressive! Many other ML Things need a lot less compute, though. Like facial recognition, spam filtering, etc.