For public spaces, at least where I am, there really isn't a legal expectation of privacy. I couldn't tell if someone was watching YouTube or filming me with their phone and I probably don't have any recourse anyway.
803 karma · joined June 22, 2011
I work at Google but these opinions are my own, not that of my employer.
Previously at Google/Google[x], Wayve, and Airbnb. Alumnus of South Park Commons.
cameron at ctuck dot com twitter.com/tuckerman https://bsky.app/profile/ctuck.com
[Verifying my cryptographic key: openpgp4fpr:135c23b218651a6275ecc71efefdf30a8e3e3078]
For public spaces, at least where I am, there really isn't a legal expectation of privacy. I couldn't tell if someone was watching YouTube or filming me with their phone and I probably don't have any recourse anyway.
Every gym I've been to is full of people with phones out in the locker room, from cheap chain gyms to the nicer athletic club I currently go to. My experience is much closer to GP.
> Glasses are passively recording
All the smart glasses I know of have a light on when recording. My phone does not and can be much more discreet (subject to the fact that everyone has a phone out already).
I agree that if a location is actively banning phone use patrons should absolutely also be asked to take off smart glasses.
I do think in a lot of fields there is a lot of impact/influence to be had by people who are willing to do work to bridge different fields. I wonder to what degree this is because practitioners don't always see how their work could be used elsewhere.
I agree making simple things sound complicated to appear more impressive is bad but there are limits. Even with Feynman he could only go so far, e.g. his interview about why questions and magnetism.
[1] https://www.theverge.com/gadgets/915508/framework-announces-...
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.
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.
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.
> 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.
[1] https://www.aalrr.com/Business-Law-Journal/californias-polic...
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.
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.
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.
I think your point still stands overall for AMD's business though, I assume a vast majority of CPUs are purchased in new desktops?
There is an official process where an engineer can apply to a committee to have Google waive any copyright claim. That requires additional work so if your goal is simply to publish the code as open source and you do not mind it living under the Google org, using the Google repo path is usually much faster.
Disclaimer: ex-googler, not a lawyer, not arguing whether or not the situation with copyright assignment is legally enforceable or not/good or bad/etc.
> Papers should be carefully crafted, not churned out.
I think you can say the same thing for code and yet, even with code review, bugs slip by. People aren't perfect and problems happen. Trying to prevent 100% of problems is usually a bad cost/benefit trade-off.
Even assuming your compute demands stay fixed, its possible that a future generation of accelerator will be sufficiently more power/cooling efficient for your workload that it is a positive return on investment to upgrade, more so when you take into account you can start depreciating them again.
If your compute demands aren't fixed you have to work around limited floor space/electricity/cooling capacity/network capacity/backup generators/etc and so moving to the next generation is required to meet demand without extremely expensive (and often slow) infrastructure projects.