Posts by cross@discuss.systems
(DIR) Post #AtpbJGrhHreKtssihM by cross@discuss.systems
2025-05-06T22:36:37Z
0 likes, 0 repeats
@ricci @usenixassociation huh. I mean, it's colocated with OSDI, so I guess I kinda see it...but the last time I went ('23) I thought it had a lot of good talks; perhaps more-so than the OSDI track.I plan on going to this one, since it's in the neighborhood.
(DIR) Post #Atpd5BQ0wLrLrXLLCy by cross@discuss.systems
2025-05-06T22:49:37Z
0 likes, 0 repeats
@ricci PS: where was this published? I can't seem to find it on the USENIX web site; curiously, they list Seattle as the location for ATC'26 (though that may just be lag in updating their web presence).
(DIR) Post #AtqmRHpYsGzQrirpa4 by cross@discuss.systems
2025-05-07T12:16:03Z
0 likes, 0 repeats
@ricci @usenixassociation this is something I worry about frequently. I, as an industry person, find it vital to be able to interact both with the academic and industrial research communities via conferences like this. I often wonder, what fills that gap? Aside from social media like this, where are all the cool kids, I mean, where do folks communicate regularly, if at all?One of the things that I miss about USENET was that it was sort of the public square where a broadly diverse groups of folks actually had deep conversations about technical topics. Nothing else seems to have filled that gap (at least, not that I'm aware of), and I fear that things are becoming more and more siloed. The loss of ATC reaffirms and amplifies those fears.
(DIR) Post #AuSH1u03lRTLtJ8EWu by cross@discuss.systems
2025-05-25T12:36:36Z
0 likes, 0 repeats
@dan ok, spill it: WHY is there a tungsten cube there.
(DIR) Post #Aub84VCoigK8gW5avA by cross@discuss.systems
2025-05-29T20:45:53Z
0 likes, 0 repeats
@lindsey @regehr @secretasianman @dan"When OpenAI's sphincter-like logo became successful, it created a template"I...kinda wish I hadn't seen that.Because now I can't unsee it. :-/
(DIR) Post #AubI3MvT19ECG14Wy8 by cross@discuss.systems
2025-05-29T22:47:00Z
0 likes, 0 repeats
@ricci @secretasianman @lindsey @regehr @dan dammit rob....
(DIR) Post #AwItXIqAfCO34OX4gC by cross@discuss.systems
2025-07-19T21:31:41Z
0 likes, 0 repeats
@ricci @dan Pepperidge Farm remembers....
(DIR) Post #AwL6PUfYUJS99y5rEG by cross@discuss.systems
2025-07-20T23:05:21Z
0 likes, 0 repeats
@ricci this. I've said before that the real benefit of these tools is exposing some cluster of data that already exists, but that we just haven't recognized yet. These are tools for experts, not replacements for novices.
(DIR) Post #AwUm4Nhn84ybygOV3g by cross@discuss.systems
2025-07-25T13:22:43Z
0 likes, 0 repeats
Hey @dev, I recognize that door!
(DIR) Post #AwWyC1LLk3lwhqE5Uu by cross@discuss.systems
2025-07-26T14:46:04Z
0 likes, 0 repeats
@shriramk interesting question. I suppose it depends in part on what you mean by "collaborative programming."Supposing that means scaling up development teams to large numbers of programmers working on a project simultaneously, I'd suggest that well-defined module boundaries, and the way that interface information is communicated across those boundaries, is something that deserves some consideration.An anecdote: when Go was starting to gain some traction at Google, I was talking to a very senior engineer who was (at the time) heavily involved in G's C++ infrastructure, and he made an interesting point: Google has O(10^4) C++ programmers working in a codebase with O(10^9) LOC simultaneously. Because of the way that C++ works, with classes often definedi n header files and included in compilation units by the preprocessor (this was pre-C++ modules, which still don't seem like something that's fully baked...), it's very easy for some programmer on one side of the monorepo to "break the build" for someone else on the other side of the mono-repo. In fact, this happened all the time (and likely still does, but I don't really know anymore).Consider the case where I add a data element to some class definition in some header. This may be a data member that is completely internal to that class, not part of the public interface, but since the interface it is still exposed _in the text of the source code_, a consumer of the interface must have access to relevant the definitions of whatever I'm adding. When I'm implementing this new thing, it's trivial to inadvertently end up relying on those definitions being in the namespace of my header indirectly; perhaps because the set of transitive includes for my project causes them to be in scope _for my module_. But it may break for you because you have a _different_ set of transitive includes, and aren't including something I introduced as a requirement.Go is different, in that modules are (or were?) individually compiled, and binary information about the types, interfaces, signatures and so forth, are embedded in the resulting object file, useable by the compiler elsewhere. The internal implementation details needed by the module are truly encapsulated in the module, and while the interface can of course change (and thus break someone), the language's compilation model eliminates this particular class of problem. The upshot was that you could have more programmers working in a language concurrently. And It's faster, since i'm no longer parsing a code from headers just to use a module.I suppose this raises something else, that I don't know has been formally addressed at the language level: versioning interfaces and tracking inter-module dependencies based on version. Usually this feels like something that's punted to the build system, but making a version a first-class property of the language feels like it would be an interesting idea to explore.If, on the other hand, collaborative programming means two or more programmers simultaneously working on the same piece of code, then that feels like more of a social and/or tooling issue, and I'm not sure how language design could help facilitate things.As an aside, I've long suspected (but have no data) that one of the reasons there's so much COBOL in the world is because it can be very difficult, without semantically aware tools, to understand when a procedure is called and from where: COBOL has this weird thing where if procedures A, B and C are written textually adjacent in a source file, one can say, "call A through C". So often when modifying something it's safer to just make a big copy of it and change the copy to suit. This is, perhaps, a great example of an anti-collaborative feature.
(DIR) Post #AwjQjkidNb03bdKOye by cross@discuss.systems
2025-07-31T12:39:27Z
0 likes, 0 repeats
Seriously disappointed in the lack of Ea-Nasir parodies in my feed right now.
(DIR) Post #AwjQjn7ATLoT2Ip1Um by cross@discuss.systems
2025-08-01T15:48:49Z
0 likes, 0 repeats
@PeterLudemann I'm thinking with this fool's new executive order about copper imports, there really ought to be SOMETHING more here.
(DIR) Post #AwjzLYtdBHpuNtfjhQ by cross@discuss.systems
2025-08-01T21:25:45Z
0 likes, 0 repeats
@brouhaha it looks like, for this specific case, Address Sanitizer finds an issue pretty quickly.```term% cat foo.cc#include <iostream>#include <vector>intmain(){ std::vector<int> v{0, 1, 2, 3, 4}; for (const auto elem: v) std::cout << "elem= " << elem << std::endl; for (auto it = v.cbegin(); it != v.cend(); ++it) { if (*it % 2) v.emplace_back(1); } for (const auto elem: v) std::cout << "elem= " << elem << std::endl; return 0;}term% clang++ -std=c++23 -fsanitize=address,undefined -Wall -Wextra -o foo foo.ccterm% ./foofoo(22239,0x20c2e5f00) malloc: nano zone abandoned due to inability to reserve vm space.elem= 0elem= 1elem= 2elem= 3elem= 4===================================================================22239==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000001c98 at pc 0x000102264f94 bp 0x00016db9a650 sp 0x00016db9a648READ of size 4 at 0x603000001c98 thread T0 #0 0x000102264f90 in main+0x6b0 (foo:arm64+0x100000f90) [snip] #9 0x000102266308 in int& std::__1::vector<int, std::__1::allocator<int>>::emplace_back<int>(int&&)+0x224 (foo:arm64+0x100002308) #10 0x000102265028 in main+0x748 (foo:arm64+0x100001028) #11 0x00019de36b94 in start+0x17b8 (dyld:arm64e+0xfffffffffff3ab94)previously allocated by thread T0 here: [snip] #8 0x000102266928 in std::__1::vector<int, std::__1::allocator<int>>::vector[abi:ne190102](std::initializer_list<int>)+0x328 (foo:arm64+0x100002928) #9 0x0001022655a4 in std::__1::vector<int, std::__1::allocator<int>>::vector[abi:ne190102](std::initializer_list<int>)+0x60 (foo:arm64+0x1000015a4) #10 0x000102264b54 in main+0x274 (foo:arm64+0x100000b54) #11 0x00019de36b94 in start+0x17b8 (dyld:arm64e+0xfffffffffff3ab94)SUMMARY: AddressSanitizer: heap-use-after-free (foo:arm64+0x100000f90) in main+0x6b0[snip]Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==22239==ABORTINGterm% clang++ --versionApple clang version 17.0.0 (clang-1700.0.13.5)Target: arm64-apple-darwin24.5.0Thread model: posixInstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/binterm% ```
(DIR) Post #AxNDwlelg50TCInCQi by cross@discuss.systems
2025-08-20T21:31:15Z
0 likes, 0 repeats
@ricci @lindsey @palvaro no way. Put real advertising on it; it could help hedge funding uncertainty in the age of ignorance we now live in.
(DIR) Post #AyAmfVqQELtONLmte4 by cross@discuss.systems
2025-09-13T19:21:14Z
0 likes, 0 repeats
@ricci brought to you by the committee for people who need to take a gun with them to go buy a carton of milk at the grocery store.
(DIR) Post #AyItKQG8CJmy9CEhk0 by cross@discuss.systems
2025-09-17T15:09:01Z
0 likes, 1 repeats
I see that Hegseth wants to administratively separate service members who have medical waivers for shaving.It's hard to imagine this as anything other than a targeted means of pushing Black people out of the military.For those that don't know, the military has "personal grooming standards" that are enforced across the services; this includes a requirement to shave daily, if applicable. This is for a few reasons: to ensure a "uniform, military appearance", but also nominally to ensure a good seal with a gas mask.However, so-called "no-shave chits" can be issued to service members for a variety of reasons, and these waivers exempt those people from this requirement.For example, I once saw a guy who had one because a tree branch or something whacked him in the face during an exercise and gave him a gnarly slice that needed stitches. He couldn't reasonably shave _over_ the stitches, so medical gave him a no-shave chit while that was healing.But the most common reason for issuing no-shave chits is for folks with "Pseudofolliculitis Barbae" (PFB), more commonly known as razor bumps, which are ingrown hair follicles on the face and neck.Razor bumps are a real thing, and while I understand they are extremely painful, more concerning is that they can become infected, rendering a service member mission incapable.But here's the thing: razor bumps affect Black folks more than others; up to 60% to 80% of adult Black men who shave regularly will experience them. The percentage among other demographics is much, much lower; like close to an order of magnitude lower. The military's own data, snapshotted in 2023, says that 63.5% of PFB cases since 2000 were among non-Hispanic Black service members (https://health.mil/News/Articles/2023/08/01/Pseudofolliculitis-barbae).And let me be clear here: this is a real, known, diagnosable medical condition, studied and recognized by dermatologists. It's not like there's some kind of conspiracy to get out of shaving or something dumb like that. And from everyone I've ever known who's had it, they'd really, really, rather they didn't. I understand it sucks.So separating service members who have medical shaving waivers will disproportionately affect Black service members. There's no way Hegseth et al don't know this."But wait a minute! What about the gas mask thing!?" I hear someone ask, "that sounds pretty legit." Ok, here's the deal: the waiver says you don' t have to shave down to the skin; it doesn't say you don't keep things trim and keep facial hare short. No one with a no-shave chit is running around with a full beard that's keeping them from putting on a gas mask.But even if they were, what about all the SpecOps guys with their "operator beards"? And anyone who's been on a multiday mission outside the wire knows there are times when adherence to the grooming standards takes a backseat to operational necessities; most of us have gone a couple of days without a shave.And if there were really a serious threat of chemical warfare and you absolutely needed to ensure you could get a seal with a gas mask, you'd shave regardless of the chit or you'd be in MOPP-4 anyway (with no exposed skin). Note that a gas mask really only covers the face and eyes; you'd be putting on a hood and other equipment to cover up the rest including, you guessed it, the area of the face and neck where the seal isn't perfect.So yeah. I fail to see any way in which this effort is anything other than explicitly racist.
(DIR) Post #AyhOOet0KBiaSOaHei by cross@discuss.systems
2025-09-29T12:51:31Z
0 likes, 0 repeats
@TaliaRinger what machine did you get? I've wanted to get into the roasting game for a while (though honestly I need to upgrade my grinder first).I've heard a popcorn popper is adequate to get a decent roast, but sourcing green beans is something I've never looked into too closely. Is Sweet Maria's still the go-to?
(DIR) Post #B068nRUB2kWeVC0pcW by cross@discuss.systems
2025-11-07T21:28:59Z
0 likes, 0 repeats
@ricci @regehr now I'm really curious who's handwriting is on the label.
(DIR) Post #B068nUJIXebdGJwga0 by cross@discuss.systems
2025-11-08T01:09:43Z
0 likes, 0 repeats
@ricci @regehr I had one of those when I was a kid. Hours of entertainment in the pre-Internet era!The "Unix News" source is interesting, but the dates a little funky. 4th Ed was late 1973; 5th about 7 months later (June '74) and 6th Ed was May, '75 and mentioned in the newsletter. Of course, points of contact for sites would have predated that; are any of you in contact with Martin Newell to ask about the tape's provenance? Perhaps he might have some recollection?
(DIR) Post #B06dO8Le9laqUHQz6O by cross@discuss.systems
2025-11-08T01:39:58Z
0 likes, 0 repeats
@ricci @regehr huh, I don't see any immediate online indication of that; no obituary or death notice on his wikipedia page or anything. Perhaps someone at Adobe knows more of his current whereabouts?