I wouldn't say it's not really a bad thing, I think it's a very good thing. There are many people now making incredibly niche products that have very good lives - making more than enough money for themselves doing interesting work engaging with customers that are passionate about their field.
I purchased the first generation of FW13 laptops and got burned. The CMOS/RTC battery drains if not plugged in so the laptop never keeps proper time. I don't think I've ever used a gadget in the last few decades that needs setting the correct date & time every time I turn it on.
Granted, it was their first ever shipping product so I gave them a free pass but I thought they would atleast issue a recall or have a repair program where you send in the laptop to get it fixed. Instead they first denied it was even an issue, later on when enough people complained - they started a battery program where they send you a new ML220 coin battery that will also eventually stop working.
I was told buying a new mainboard (12th or 13th gen Intel) would fix it, but I decided to just buy a new ZenBook instead.
The permanent fix involves soldering stuff on the mainboard, which I don't have any prior experience. The RTC substitute module you mention is just the ML220 coin battery that will also eventually stop working.
I did this repair and it was not nearly as easy as you imply. The wire is extremely thin, and the pad on the motherboard is extremely small. I had to purchase special eye-wear in order to see what I was doing, in addition to a soldering iron.
It was and is totally wrong that Framework requires users to repair a component that was faulty from the factory. You should ship the laptops back to your facility and repair them, at your expense. At worst, offer a substantial discount on a motherboard replacement.
This experience is a big reason why I went from a strong Framework proponent to a strong detractor. You do not support your products, and users cannot trust you to do the right thing. You now bask in the idealistic haze of nerddom but your actions show that you're just a business for whom repairability is a sales strategy to justify premium prices.
The warranty suggests that Framework would "ship the laptops back to [their] facility and repair them, at [their] expense," as you said they should. Did that not happen while your warranty period was in effect?
The issue did not arise until after the warranty period expired. The manufacturing flaw drained the real-time clock battery which lasted about a year. Their first fix was to send a new battery; the second fix was a soldering job. I am not a lawyer, but this does not seem like it is legal. The manufacturing flaw was present from the beginning but was masked by the battery's charge.
I appreciate the response, but my suggestion would be to offer a mail-in service program so that users don't have to fiddle with potentially dangerous soldering (ideally Framework bearing the shipping costs or atleast subsidizing it).
I switched to Orion from Safari a few months ago and so far loving it. I tried Orion a couple of years ago but it wasn't as reliable. Now it seems very stable and the kagi search integration is really nice.
On a side note - I don't know why Apple still doesn't let you set a custom search engine in Safari even today, so random.
I'll add another point i.e. Odin is effectively done from a language point of view unlike Zig or others. The project is currently working on improving the std library and toolchain but the language itself is finished according to it's BDFL.
From my experience so far, Odin is a delightful modern alternative to C.
Zig is still pre-1.0, and the creators have been VERY clear that they're not done breaking stuff on the way to getting things right. It's a fair contrast to draw.
to be fair at this point it seems like outside of reenabling async control flow, and eliminating cImport, the remaining major shifts are in the stdlib and not as much the language. they have cancelled the "forcing const f = fn..." plan. i think the interesting thing that andrew hinted at was keeping the "annoying errors that should be warnjngs" (like not using consts and vars) but not letting them prevent the creation of the executable/lib.
note: not all of these are language changes (affects substantially how you write zig) -- many are features and optimizations, true they could affect how you think about zig (inlining monomorphic function pointers), but most people will not notice. Of the ones that are language changes (requiring parens for ambiguous operator precedence, e.g.) many will be automatable and bundled with zig fmt.
Hi, are you interested in Zig? Then please check out my port of jsmn to Zig. I wanted to know if people will like it and if there are any downsides others might not.
One can use `@(require_results)` to force the user to check for error. That paired with `or_return` or `or_else` in Odin mostly take away all foot guns.
Great write up and I share very similar ideas. But I wish there was something a little more than a library where people with similar interests can actually socialize and build a sense of community.
I need that too! Especially when working remotely, I don't have the office to see my co-workers to socialize. Or back when I was in college, I don't have my classmates to chat about stuff. I wish "clubs" or communities in that sense were more common outside of college
The ampersand implies that a value will be written to to me (though it's slightly more complicated because many ABIs are inefficient with structs passed-by-value so it's occasionally used for efficiency there as well).
Fannie and Freddie are supposed to be there to stabilizing home lending rates. If they are public and have a profit motive, then their mission changes to profitability over stability.
Can't comment on RTTI, but lack of conditional imports are indeed an annoyance but I'm willing to put up with it because of all the other niceties in the language.
You technically _can_ do conditional imports by mis(?)using the #load('') usage, its not perfect and might not work for all cases, but it can be done since #load() loads a file/entity in at compile time. It's a 'hack' but it can be used that way.
reply