My heart sank when they said 13 pro and then to see that so much is backwards compatible was amazing. It's quite refreshing to see a company live up to their mission so well.
Yeah, really impressive to see that you can take a 13 and turn it into a 13 pro with just a few new parts.
I've just ordered my own 13 pro. I've been waiting for a laptop and this ticks all the boxes. I'd previously ordered a new dell xps laptop and ultimately returned it because the keyboard was busted. I would have kept it if I could have swapped the keyboard for a new one. The use of LPCAMM is also really nice. I've hoped to see this standard start taking flight and I'm happy to grab a product with it included.
I'm not in the market for a Windows or Linux machine myself, but the way this company operates I feel like supporting them with a purchase at some point regardless.. maybe their Desktop tower
Same, though the battery upgrade alone will be around $260 because of the new bottom cover, at that might just throw in the speaker upgrade as well for $19.
Not sure if I even want a haptic touchpad at all.
It's a matter of preferences. Actually I like trackpads that don't mind and have physical buttons. The separation between the surface that moves the pointer on screen and the surfaces that generate the clicks means that there are no misclicks and no involuntary pointer movements while clicking.
There is no accounting for taste.
For instance, I still prefer discrete buttons over tap-clicks or multi-finger-taps, but I would accept the mild annoyance of tap clicks over the pressing down the pad itself.
Haptic schmaptic, I just want my Framework's enormous trackpad to respect deadzones and stop detecting my palms. I had to entirely disable tap-to-click, because nothing else would work.
I might have to try their preinstalled Ubuntu images or something and see if there's some secret sauce in the input configs.
Not a huge fan of the "force touch" trackpads on newer macs, the old man yells at the clouds.
In all seriousness though I have used a pre force touch MacBook not too long ago and I prefer that experience a lot over the new one I have from work.
Though the larger size of these trackpads is something I really like and where neither the older MacBook nor the the current non-pro Framework 13 come close.
I did last year after deciding that Apple's software just isn't for me anymore. I've always had a Linux desktop around (and used to daily drive Linux on a laptop years ago) so I was happy to consolidate on my preferred platform.
Biggest gripes I had are:
A) battery life (both during use and standby just kinda sucking on Linux in general compared to os x, not exactly framework specific but I did get used to how amazing my m1 pro for longevity)
B) the case looking nice but feeling a little flimsy
C) the speakers are pretty bad (though I did get turned on to easyeffects and there is a profile for the 13 which helped a bit)
D) macs completely spoiled me trackpad wise
It seems like they are taking a stab at all of these in some way and I'm excited to see how it goes, especially with so much being backwards compatible.
All the same gripes from me. None enough to be a deal breaker, but every once in a while I'll do something on my GFs macbook pro and be blown away by how solid it feels.
I was pleased to see that The Verge's coverage of the event [1] was very positive on the feel of the laptop (even saying they got the hinge feel right like on the macbook which was the first thing I noticed being "not quite right" with the framework when I got it). I'm optimistic that this will be a big step in the right direction.
I don't know who you think the "real family" is but a) narrowing what a real family is does an awful disservice to a whole host of unique families, not just families that involve surrogacy and b) nearly all surrogacies in the US are gestational surrogacies where at least one parent is genetically related to the child and the surrogate is not at all related to the child (not that genetic relations is what makes something a real family or not, but I'm pretty sure thats what is implied here).
I think he's just trying to remind people that someone can both be a CEO of a powerful company you might disagree with/hate as well as a real human with a husband and child and that trying to set fire to his house could kill those people.
I personally wouldn't go as far as to say the Farrow article caused this but it seems fair game to respond to an article that had an over the top cover image of an animated Sam Altan picking and choosing faces with a photo reminding people he's human like everyone else.
Robinhood gets double shame points for naming the app "Banking" (previously "Credit Card"), no Robinhood or RH in the name. I love the card but hate everything about that app.
The site that irks me the most here is New York Times. Opening an article in the mobile browser often has a toast over the bottom third of the article to open it in their app for "a better experience". I struggle to think how nytimes isn't a perfect fit for a site over an app. The only frustrating experience I have with the web version that would be better in the app is not seeing that that pop-up.
I recently signed up for a membership (you can now supposedly cancel without making a phone call; WaPo has officially died in darkness) and this has been driving me mad, too.
If I'm paying for your service, you should not be degrading my experience using UX anti-patterns in any way, for any reason.
For games I agree that an app makes sense (though I think at least the games I used to play were in a separate nyt games app). For interactive articles, I've not seen anything I couldn't use fine in my browser, but in theory I wouldn't mind covering up the interactive part with a "Open in the app for a better experience" button (similar to what YouTube does on the video portion of the page). Where I encounter this though is in standard, text-heavy articles that maybe include a photo or two.
I assume the reason they are pushing me to the app is that it benefits them not me (longer dwell times, maybe easier tracking for behavior/ads), and that is precisely why I want to stay in the browser. Covering up a good portion of the article and preventing me from scrolling until I click the tiny link to decline is hostile and is the only thing degrading the experience on the website for most articles I read.
For arbitrary contracts I would agree, but I think increasing the limitations in severance agreements specifically makes sense. There are already certain requirements (at least in California) for severance agreements and I think limiting the duration of non-disparagement clauses to 1-2 years would be a positive change.
I don't have much skin in the game but as a passerby, I agree that the report obviously was made with a lot of time/effort but wouldn't dramatically change someone's view of Ruby Central or assure anyone this won't happen again. This is like writing an outage postmortem without really getting to the root cause and identifying what can be done to prevent in the future.
That wasn't my read of what the postmortem is claiming. I didn't see a claim that anyone did anything illegal with proprietary information and the only legal question anyone raised was around a tangentially related proposal with user data[1]. I think the question about working on competing work is unfortunately more grey than most on HN would like, but even then nobody was fired/terminated for that. It sounds like people voluntarily left.
My biggest takeaway from this is the intermingling of opensource work/foundations/companies and employees/contractors/volunteers needs to be incredibly explicit. It sounds like everyone had very different expectations about what this group of people was (ranging from an exclusive club of influential ruby developers to a very formal, business-like foundation) and, as a result, each other's actions seemed hostile/strange/confusing.
[1] I actually think the comments about the proposal of selling the user data does a disservice to the postmortem. I think it invokes a much more emotional reaction from the reader than anything else and, while potentially interesting, seems like dirty laundry that doesn't change the lesson the postmortem teaches.
The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened. You and some others here might have much more context that I or other readers of this postmortem don't have.
I seem to remember there were some threats of legal action related to unauthorized access after this kerfuffle but I a) don't know what is going on with that, b) don't know what the law actually says about that and c) don't know if that is what you are referring to. If so, I think it is different than what the original comment alleged which was more about moonlighting/using proprietary information/competing. I think that topic is extremely complicated (e.g. I am not so sure moonlighting for a competitor while an employee is necessarily protected in California...) but that wasn't alleged in the postmortem anyway.
> The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened.
You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal. For example:
1. André's first commit on RV is placed on the same bullet point as the Ruby Central-funded maintainer offsite, which implies Ruby Central's travel money subsidized a competing project's creation.
2. The `rubygems-github-backup` access token covering "all repos, including private repos" is introduced in the same timeline section as RV development, without any allegation it was used for RV.
3. The "Incident Lessons" section recommends adding an "Outside Business Activities" declaration policy, which only reads as a "lesson" if André's undisclosed side project is being framed as the problem in need of remediation.
4. The report states André "had intimate knowledge of the foundation roadmap" and "did not tell anyone in Ruby Central about this work until it launched". This frames nondisclosure of a lawful side project as a transgression. However, Ruby Central passed on this work, and even if they didn't, André has no obligation to tell Ruby Central about his work!
5. André's proposal to have his consultancy analyze RubyGems.org download logs is presented alongside an OSS Committee member raising PII and "reputational risk" concerns, casting a perfectly sensible rejected business proposal as something suspect.
By my count, Ruby Central makes roughly 10 insinuations throughout the report, but not once do they actually claim any of these constitute a transgression.
> I think that topic is extremely complicated (e.g. I am not so sure moonlighting for a competitor while an employee is necessarily protected in California...)
California is actually quite clear on this! Bus. & Prof. Code § 16600 voids non-compete agreements, and California courts have consistently read it broadly enough that working on a competing project during employment is protected. The line is whether you used your employer's proprietary information or resources to do it, not whether you competed. The report does not allege that Samuel or André used Ruby Central's proprietary information, and given how thoroughly they documented everything else, I'd expect them to have said so if they had evidence of it. Ruby Central is insinuating that working on RV in the first place is a problem, not that they crossed any legal or contractual line.
I might be reading it wrong, but it sounds like you and some others here are either more closely connected to the folks involved or at least have more context. I don't want to imply that I know better what the author or anyone at Ruby Central _actually_ believes or is doing, I'm just commenting on the article at face value. Whether the article is true, deceptive, or in between, I think there is still an interesting general lesson about organizations in it.
> You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal.
I think we just took away something very different from the article. I didn't read it that way, I read it more as "these two have already decided to move on to work on this without Ruby Central so it's pragmatic to cut off their access". We might just need to agree to disagree on what the article implies; perhaps we are just reading it with different boundary conditions.
Where we might agree is that repeatedly bringing up the selling user data proposal doesn't add anything to the story except to prejudice the reader against Andre. If it's to show that there was still some communication between Andre and others at Ruby Central, I would have kept it at that. Every time it got mentioned I winced.
> California is actually quite clear on this!
My understanding is quite different. There is a duty of loyalty an employee owes their employer and directly competing with your employer is clearly a breach. There is recent enough case law on this (at least covering terminating an employee for cause as a result). I don't have access to the materials from a previous employer that explained some of this but I did quickly find [1] which roughly agrees with my recollection (though I would not be willing to vouch for this particular site), namely "that Section 16600 has consistently been interpreted as invalidating any employment agreement that unreasonably interferes with an employee’s ability to compete with an employer _after_ his or her employment ends".
I'm not a lawyer (I assume you aren't either but at the very least you aren't _my_ lawyer) so I think it's not worth debating this further, we seem pretty firm in our beliefs on this one.
EDIT: I want to acknowledge that one of the individuals here was a contractor and not an employee. I have no idea how that factors into moonlighting restrictions. I imagine it would be more limited and lean more on what that individual's exact role is at the company? I think my point still stands that my understanding is that the general situation for the average software engineer is more nuanced.
There is a lot of tension that the report seeks to either minimize or avoid. It’s also just really hard to express it in a report like this because there’s no real place for it if the goal is to look professional.
I think the RubyGems fiasco was a result of unresolved tensions. People chose not to be adults about and resolve the issues respectfully. IMHO, I think one of the main problems is that nobody was willing to spin up a core foundation to own critical infrastructure to the Ruby community which remains a problem.
I cannot find the blogposts I remember reading, but recall that there were some bad feelings about Ruby Together and Arko’s leadership of it before it was merged with Ruby Central. It appears these feelings never went away which is made very clear by the way that key Shopify engineers started posting after Ruby Central took over the RubyGems GitHub org [1].
Now combine this with dhh’s right-wing political posts and behavior, his extremely close relationship with the founder of Shopify (dhh is on the board of Shopify), a key Ruby Central donor pulling critical funding because he did not want his money going towards giving dhh more attention and you’re left with Ruby Central effectively being controlled by Shopify (which, as far as I can tell is still the situation) because that’s where all of its funding comes from now.
Frankly, the biggest thing this entire fiasco has shown me is that a lot of us are still a bunch of idiotic teenagers. Integrity and maturity is in short supply where it is needed the most.
> I cannot find the blogposts I remember reading, but recall that there were some bad feelings about Ruby Together and Arko’s leadership of it before it was merged with Ruby Central.
I agree that's likely true but I'm not sure if there are any jurisdictions finding things differently? I'm not aware of any rulings from appeals courts with broader jurisdiction but I imagine if they don't exist they will soon.
reply