Threads for GeoffWozniak
-
I agree with the thrust of this, but the choice of the troubleshooting example is pretty unfortunate, I think.
Two engineers separately attempt to identify the root cause of the issue, but are unable to find the source of the problem after a week of investigation. A third engineer is brought in and is able to identify and resolve the issue within a few days.
[…]
It may make more sense to ask the third engineer to train the other engineers on their issue resolution methodology.
I’ve been that third engineer on multiple occasions and the problem is, in a lot of cases I’m not doing anything I could train anyone else to do even if they asked. In some cases even I don’t understand how I figured a problem out.
“Train someone else to resolve issues the way you do” presupposes that I have a well-defined checklist in my head that I methodically proceed through until I get to the step that resolves the problem. For simple problems, that’s kind of true, and I can tell people what I’m doing. But for the not-so-simple kinds of problems that would cause another team to ask for my help in the first place, it’s more like a series of intuitively-guided attempts to match against different patterns of problems that have puzzled me over the course of my career. My intuition is usually decent and before long, I have an “aha” moment. Then the person I’m working with asks, “How the heck did you know that was it?” and I have no answer.
If a manager comes to me and says, “Hey, can you take a couple weeks to train our team to pattern-match against your 35 years of professional experience?” it’s not going to be a useful exercise.
-
I think it can depend on the specifics. Sometimes when I find bugs, it’s something I can’t communicate to other people. In other cases, it’s because I knew a tool or approach that other people didn’t. Like in one case I solved something quickly because I was the only person who knew how to load old database snapshots. Showing other people how to do that meant they were able to solve similar issues quickly, too.
People also gather information differently, and watching how a more senior person gathers information can teach you useful tricks. Think things like
git bisect, writing testing scripts, using a debugger, even recording theories in a notebook.-
In other cases, it’s because I knew a tool or approach that other people didn’t.
There are many cases I’ve seen in my years of a bug taking a long time to solve because of lack of knowledge of tools that would make things easier. There are two main aspects to this that I’ve noticed:
- The person doesn’t know how to use the tool effectively, be it the knowledge of an option or configuration parameter.
- The person does not know about the tool at all.
In the second case, it is usually accompanied by an ignorance of the questions that the tool opens up to you. If you don’t know that you can attach to a running process to debug it, for example, then you tend not to ask questions about dynamic analysis or profiling. (Admittedly, this is a bit of a crude case, but the point stands.)
Teaching the first point isn’t so hard. Teaching the second one can be a bit trickier.
-
I tend to use the technique that Raymond Chen refers to as ‘psychic debugging’: from what I know of the codebase, think about how I could introduce the bug, then come up with an experiment that tests whether this is actually how the big was introduced. The second half of this is teachable because it’s just a set of recipes. The first bit is probably something that you can learn only through experience because it’s the same skill as introducing desirable features (and if we had a reliable way of teaching that, the software world would be a much better place).
To the original example, it’s very possible that two people using this exact process would take different (but not reproducibly better or worse) times to find the same bug. I’ve spent days chasing bugs in the wrong place before and I’ve also found a bugs in minutes that other people spent days failing to find. It would be easy to cherry pick one of those examples and say that I am amazing or terrible at debugging and should teach / learn from other people, but often they were following exactly the same process. In some cases, the slow and useless person was tired me, the fast person was well-rested me.
-
-
Thanks for the feedback.
I used the example because it’s something that actually happened - the third engineer in the example actually asked me if it was okay for them to apply “go slow to move fast” and if we could accept slower resolution times in the short term to give them an opportunity to train others, and it turned out to be a great success for us.
I can certainly agree that it’s not something to be applied in all situations, and I wouldn’t ask someone to do this if they thought it wouldn’t be productive!
-
-
-
But for the not-so-simple kinds of problems that would cause another team to ask for my help in the first place, it’s more like a series of intuitively-guided attempts to match against different patterns of problems that have puzzled me over the course of my career. My intuition is usually decent and before long, I have an “aha” moment. Then the person I’m working with asks, “How the heck did you know that was it?” and I have no answer.
This has happened to me more than a few times. My only advice to my team members is to read a lot and read broadly. Just because something doesn’t seem like it is relevant doesn’t mean it won’t come up. Additionally, it’s important to understand the underlying architecture of projects, the fundamentals of environments, or the supporting theory behind constructs. If you only understand the API then your debugging tools will be limited.
-
-
This is a puff piece with no relevant content.
-
I disagree. It’s futurism, so it could be wrong, but the idea that the easiest to use UI for apps has switched from a GUI to a command line is interesting. It had been observed for some time that Google is like a CLI but this takes it to a new level. Will it actually work out? Time will tell. But if you’re thinking about where the business opportunities are for programmers, it would be silly to not at least examine if LLMs could help your project.
-
It misses the key thing that drove GUI adoption in the first place: discoverability. In early CLIs, it was easy to list the full set of commands available in an OS and then full set of options for each one. In DOS, I think it took two screens to list every single command available in the default install. As CLIs get bigger, this become harder because their designs were verb-noun. GUIs make it easy to show the set of verbs that are possible to apply to a specific object, which lets the user discover what the tool can do much more easily. It’s possible to design noun-verb CLIs (PowerShell has enough type info to do this, but decided to make some very poor choices from the perspective of usability). A natural-language prompt is the absolute worst thing here because it gives the user no information about what is possible and relies on their ability to scope queries to something that might work.
-
I think LLMs change the calculus here because it’s feasible to say, “I’m trying to get the average total value of all the monthly reports” and the LLM can shoot back “Use this code AVG(C5:X5) SUM(B5:B18)”. You don’t have to know that getting the average is AVG and getting the total is SUM. You also don’t have to preprogram in all the synonyms for the functions. Just write a bunch of documentation for one shot learning (and that can also be AI assisted) and let it go.
-
-
Typing is still tedious and time-consuming for an average user. It might be more convenient combined with voice, but that depends on user preferences and environment (e.g. open-plan office).
So I’d expect basic operations to still use classic buttons. Instructions may be useful for learning (“show me how…”) or tasks big and complicated enough that it’s easier to describe and delegate them than to do them yourself. However, the AI needs to be really good at this, so that checking the results and correcting it isn’t worse than doing it yourself.
-
-
The point of the current LLM tools is that it is possible to iterate. So there can be some back and forth between the user and the AI. The AI can even do the breaking down of a task for the user.
This is most likely not faster than a power user that knows how to click the right buttons or type in the right commands. But it is probably a lot faster and definitely a lot nicer experience for everyone else.
-
And we’re just witnessing the early beginnings of this kind of human machine interfaces. Imagine that the AI that’s assisting you has a personal profile of you where it remembers years of context about who you are and what you work on and what your current task is. Add on top of this the addition of voice and even body language through the web cam and then imagine what kind of interactions are possible.
-
-
-
-
-
-
-
GeoffWozniak
17 days ago
|
link
| on:
LLaMA-rs: A Rust port of llama.cpp for fast LLaMA inference on CPU
Welcome to Lobsters! Self-posts are fine but avoid putting commentary in the text field, as per the submission guidelines (seen when you go to submit):
When submitting a URL, the text field is optional and should only be used when additional context or explanation of the URL is needed. Commentary or opinion should be reserved for a comment, so that it can be voted on separately from the story.
-
-
I don’t know about anyone else, but I tend to demand correctness from the compilers I use.
-
Me too, but it seems like we’re all about to tip into an age of telescoping justifications of probabilistic incorrectness. This article is a great example: it sounds like it demonstrates an understanding of what a compiler is, until you think about it for even a second and it becomes clear that there’s no real semantic comprehension in evidence, just a particularly sophisticated form of word association. I’d honestly suspect that it were just the output of an LLM except for the fact that an LLM would be very unlikely to misspell “steroids” as “steriods” as has been done here, and also I don’t think LLMs have yet mastered the art of being this insufferable in their use of typographic emphasis.
-
-
Someone at work used ChatGPT to generate some code for doing interrupt handling of floating point registers. It was subtlely wrong. At first glance it looked correct, but upon closer inspection it has a bug that, if not fixed, would cause confounding errors in ways that are incredibly hard to track down. It is the kind of error that corrupts data and would show up far away (in space and time) from the actual problem. In other words, a nightmare bug.
The generated code would save no time here. You still have to go read the spec and understand how everything works to ensure that the code is doing the right thing. That’s where all the work is.
-
I still find the ‘it’s great for boilerplate’ claim in the article depressing (though true). If a large language model has enough data points to sample that it can fill in what you want by making some tiny tweaks to something it’s seen in thousands of examples, why do you need that in your source code? Whether a human or an algorithm write the code, humans still have to understand and maintain it, so the cost is still there (if anything, being able to write it more easily makes it easier to write larger, and less maintainable, codebases). It really shows how far we still have to go in producing usable programming languages and frameworks.
-
I heard the ‘great for boilerplate’ part often enough that I figured I’d test it a while back, based on an acquaintance of mine’s observation that ChatGPT can come up with remarkably correct code when asked for a minimal IIO driver. A device driver for a somewhat obscure Linux kernel subsystem seemed like a good test case for that – it’s something I’m familiar with, something I also had to implement in alternative ways, and also there’s a lot of boilerplate involved, at several levels, from “this is a Linux module” to “this is an SPI device attached to this interface” to “this is an IIO driver which will present values on these channels”.
Thing is, most of that is “true” boilerplate only for simple devices. All those innards are exposed primarily in order to support more advanced use cases, like sharing device driver code between multiple variants of the same device (e.g. same ADC with different channel counts and sampling frequencies) or allowing the programmer to enforce things that the hardware expects to be enforced at the other side of the bus (e.g. no new requests while the hardware is working on another request, minimum time between consecutive requests etc.).
For the most simple of devices, you don’t really care about any of that, and you’re left with boilerplate you copy-paste around – something you could, indeed, presumably tuck under a generic “make me an IIO driver” language macro, or a generic IIO device driver that you just hand off a pair of read, write functions to.
For more advanced devices, though, all that is “just” initialization logic, not generic boilerplate. Where one ends and where the other begins is hard to say. For every step in a more advanced driver, I can sigh and think you know, I wish this was just a config parameter somewhere. But a config definition format that can really describe all these quirks would just be a really awkward DSL with imperative features. We all know how that goes.
Thing is, ChatGPT is great at the former kind of boilerplate, but years away from the latter. If I ask for a minimal IIO driver, it gives me one (literally one that just probes but, hey, I did ask for a minimal one). If I ask for a minimal IIO driver for an SPI device, it gives me one that just probes, but also reads and writes some junk on the SPI bus (which it doesn’t use in any way). By the time we get to specific things, like write me an IIO driver for this particular device attached via this particular interface, ChatGPT comes up with “boilerplate” that’s loosely related to the prompt but otherwise firmly into well, at least it compiles land – it writes made-up values at made-up addresses, sometimes on made-up buses. (This isn’t unexpected, and is obviously an artefact of training data availability: if I ask for the driver for a device that’s already supported in the kernel, it basically just give me the existing driver code, minus the license :-P).
Linux is probably not the pinnacle of solid, reusable kernel frameworks, but it makes a trade-off that’s familiar to all of us – it trades verbose, but mostly default code for simple cases, in order to make it less painful to allow customization for more advanced cases. ChatGPT is overwhelmingly biased towards the former because they are bound to be more represented in its training data and because it’s inherently better at generating that kind of data. However, that’s not necessarily representative of what a human programmer needs.
-
If a large language model has enough data points to sample that it can fill in what you want by making some tiny tweaks to something it’s seen in thousands of examples, why do you need that in your source code?
I think the same thing, and it’s also why I don’t consider it all that impressive. If it’s generating boilerplate, why is that code required in the first place?
-
-
I needed to write a thing to turn a 1D array into an N-dimensional array two days ago. I tried Googling “golang N-D array” but couldn’t find it. So then I tried Googling Python N-D array and got solutions that were the opposite of what I wanted (going from N-D to 1) or just 1 to 2-D. So I tried asking ChatGPT to do it in Python and it gave me a good solution, and then I asked it to translate it to Go, and it did a good job. Maybe the code has a subtle bug I haven’t noticed yet, but it probably cut 2 hours of noodling with a pen and paper down to half an hour of searching and reviewing.
Here’s the version after I cleaned it up by making it generic and removing an unneeded else branch:
func inflate[T any](lst []T, shape []ArrayDimension) any { if len(shape) == 1 { return lst } dimSize := shape[0] dimShape := shape[1:] result := make([]any, dimSize.Length) sublistSize := len(lst) / int(dimSize.Length) for i := 0; i < int(dimSize.Length); i++ { startIdx := i * sublistSize endIdx := (i + 1) * sublistSize result[i] = inflate(lst[startIdx:endIdx], dimShape) } return result }This is pretty much the ideal use for ChatGPT because it really is just a semantic search of existing code. I would have been just as happy if Google had given me the webpage of someone else writing out the algorithm, but since a keyword based search can’t distinguish converting 1 to N from N to 1, Google-style search failed.
-
-
There’s an outer function that calls the inflate function after checking the size is correct. I don’t want to repeat the check on every step of the inflation. See https://github.com/jackc/pgx/pull/1511/files
-
-
-
Someone at work used ChatGPT to generate some code for doing interrupt handling of floating point registers.
Ouch. That is also the last thing an LLM should be used for. One could potentially use it to generate test cases. The future in this area is to have an LLM connected to a theorem prover so that the output can be checked.
-
-
I think the better question is, who cares?
The Turing Test hasn’t really been relevant for a long time. It was considered kind of a joke when I was an undergraduate in the late 90s.
-
-
-
-
I don’t know about the 90s, but a chat bot “passed the Turing test” in 2014 (https://en.m.wikipedia.org/wiki/Eugene_Goostman).
-
Goostman is portrayed as a 13-year-old Ukrainian boy—characteristics that are intended to induce forgiveness in those with whom it interacts for its grammatical errors and lack of general knowledge.
Uhm… that’s a bit of special pleading.
A “real” Turing test would be to present either participant (the ones questioned by the interrogator) as “peers”, such as adults with English[1] as their native language. Ideally the interrogator would also know that they were taking part in a Turing test, and could therefore “probe” accordingly.
Considering the great interest in and the general availability of ChatGPT I’m surprised no-one has tried the Turing test with it.
[1] in this case, as I believe ChatGPT is English-only.
-
-
-
Given that 50% would mean that the human’s guesses are as good as random, yeah, 30% is pretty significant. If it fooled the human 100% of the time that would somehow imply that it comes off as more human than human.
-
If it fooled the human 100% of the time that would somehow imply that it comes off as more human than human.
I assume most of my interactions (outside stuff like automated customer service chat support) is with a human. So far, I’ve not had reason to suspect that ~5% of every text-based interaction from an entity is actually created by a computer…
Edit removed question answered in the Wiki article
-
-
-
-
-
-
This is a great argument for never using C for any serious application.
-
-
Everyone makes mistakes sometimes.
-
In my opinion, it would have been a mistake had there been better choices available. C was one of the very few languages that made life easier for programmers (recall most were using assembly back then), and offered the desired performance benefits of being close to the machine. And it was a small language, allowing quick learning and unparalleled flexibility. Of course, that flexibility came with a tradeoff – it was much much easy to shoot yourself in your foot (and we continue to see these footguns even today!)
Even today I don’t see any formidable opponent to C when it comes to implementing the OS kernel, networking stack, filesystems, and similar serious applications. Rust may be the C replacement, but we have to wait to see where it goes.
On that note, I recall an argument about using newer memory-safe language as a replacement for C on the OpenBSD mailing list, and this email from Theo de Raadt is worth pondering over: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2. If someone cares, the entire thread is worth reading.
-
For instance, rust cannot even compile itself on i386
I was (begrudgingly) agreeing until here.
-
-
The part I find objectionable is the idea that not supporting i386 is a terrible problem for a new language.
-
You can program Rust just fine on OpenBSD/i386. What you can’t do is include it in the base system.
In OpenBSD there is a strict requirement that base builds base.
As long as at least one supported architecture cannot build Rust from base, it’s not going to get into the OpenBSD base system.
-
-
-
-
-
-
-
-
I am not moved by all the examples, but the sentiment is correct. Mentoring should be happening a lot more than it does now.
-
Yeah, I disagree about some (
iforever! Refactoring belongs in the shell, not the editor!) but I fully agree about the aggregate point.I guess a counterargument would be that some things (such as IDE) are more a matter of personal comfort than objective correctness.
-
The difference between a text editor and an IDE is very blurry now. Is VS Code a text editor or an IDE? What about Vim + ALE? My text editor has auto-completion, cross-referencing, and can drive a build, but I tend to debug with lldb on the command line (I still miss
dddsometimes), though there are plugins for integrating it with my editor as well.-
Is VS Code a text editor or an IDE?
Yes. XD
-
-
-
-
I thought this was a good list, but it’s missing one really important aspect: write documentation.
-
And, related, write tests. Tests in a library can help users because they can read them and see if they’re using the library in an expected way. A good testing framework also makes it easy for downstream users to submit tests that ensure that you don’t break something that they depend on.
-
I think the author didn’t want to state the obvious about making the library. It’s all about the extra bits around the design. Which is great advice. Besides that sure, you’ll have to write the functionality, the tests, the docs.
-
-
I wasn’t entirely compelled by the argument, although I see where the author is coming from. But I did not like the clickbait title.
From the introduction:
Software maintenance is simply software development.
From the conclusion:
So, let’s stop talking about software maintenance is if it were a separate activity. It is not. It is just software development.
According to the author there is software maintenance: it’s the same as (or a subset ot?) software development.
What I didn’t find compelling from the article was the lack of depth. If they are the same, then why not explore it further? Would (or why don’t) developers start to refer to themselves as “software maintainers”, for example?
Anyway, the article is thin and only raises an interesting point of discussion without doing much to answer it, aside from platitudes one might expect from Uncle Bob.
-
It’s also missing the whole responsibility angle. At least in open source, but probably also in a lot of proprietary contexts, there is one or a small group of “maintainers”; stewards of the project. These people are responsible for creating a roadmap with planned features, reviewing and integrating code submissions from non-maintainers, etc. Maintainers are usually also developers for the project they maintain, but they don’t have to be.
If I start contributing to some project, I am a developer who does software development for that project. I am not a maintainer, as I have neither the privileges nor the responsibilities associated with maintainership.
When we ask questions such as “who is the maintainer of Git” or “who are the maintainers of Linux”, there are clear, unambiguous answers which carry real significance, and it is very difficult from the questions “who are the developers or Git” or “who are the developers of Linux”.
-
-
That’s a very interesting insight, really. But I fear it might not make any difference in practice.
-
-
-
I have never understood why no one simply uses separate call and data stacks. The performance should be just as good (perhaps slightly better—IIRC, you get to shave an instruction off of the prologue), and it can be made ABI backwards compatible (and close to forwards compatible, though there are some wrinkles). When the call stack is put at a random address, it should be pretty much impossible to leak it (since there is no reason to create a pointer to it), and so ROP becomes basically impossible.
-
You’d need an extra register and you’d need to push and pop things from two stacks in the common case. This is what SafeStack does and you can see the published perf overheads.
SPARC has a somewhat better model. The abstract model for SPARC is an infinite number of register windows. You have some shared with the caller and some with the caller, so you usually don’t need to explicitly push or pop (unless you have a lot of live values in a function). In the hardware, there is a finite number of windows, arranged in a ring, and you take a trap and spill them when you run out (you can also spill them all on context switch and then reload them on demand). The very last generation of SPARC processors did what the first generation should have done and spilled them asynchronously in the background. This meant that the CPU could spill whenever the store units were idle and not worry about memory ordering because it is undefined to access that memory region for anything other than spills and reloads without some very aggressive barriers.
-
You’d need an extra register and you’d need to push and pop things from two stacks in the common case
But you get to skip frame pointer maintenance, because the call stack frames are all the same size. If you have hardware call and ret instructions (as x86 does), it actually ends up as a minor win for the split stacks.
The reason safestack super sucks is that it keeps the other stack pointer in a tls, not that it uses multiple stacks.
In the time since I wrote that comment, I decided that probably the reason no one’s implemented the scheme I’m thinking of is that it’s extremely fiddly (when you take into account compatibility). I am going to see about implementing it.
-
But you get to skip frame pointer maintenance, because the call stack frames are all the same size.
Only for one of the stacks, you’d still need it for the other one.
The reason safestack super sucks is that it keeps the other stack pointer in a tls, not that it uses multiple stacks.
At least one of the implementations used a separate register, but this was a bigger ABI break.
-
Only for one of the stacks, you’d still need it for the other one.
You can make the call stack frame a pair of a return address and data stack pointer. On x86, the prologue becomes: ‘push rbp; sub rbp, stack-bytes-used’, and the epilogue is simply ‘pop rbp’ (assuming rbp is the data stack pointer, and I think it’s probably the right choice).
(The alternative is you skip frame pointers and do fancy DWARF stuff. This can be done both with split stacks and with a unified stack; split stacks are still a wash wrt instruction count given hardware call/ret, but have the important advantage that you can very easily and cheaply sample the call stack, e.g. for logging or profiling.)
At least one of the implementations used a separate register, but this was a bigger ABI break.
Have a link? I looked into it a bit earlier today, and found this comment:
// FIXME: use a dedicated register for it ?
From 2016. Regardless, I aim to maintain ABI compatibility.
-
You can make the call stack frame a pair of a return address and data stack pointer
That’s just moving the frame pointer onto the call stack. Probably not a bad tradeoff, since you rarely need the frame pointer (especially on x86, where you can have large immediate offsets for stack addressing).
On x86, the prologue becomes: ‘push rbp; sub rbp, stack-bytes-used’, and the epilogue is simply ‘pop rbp’ (assuming rbp is the data stack pointer, and I think it’s probably the right choice).
But now you can’t use push and pop for spills on the stack. That’s similarly a problem on AArch64 where there are some special behaviours for sp-relative loads and stores. Intel put quite a bit of work into making LLVM use push and pop instructions, because they make the prologs and epilogs smaller, which has a quite measurable impact on overall code size. They also do some very exciting things with push and pop in the decoder to make them able to execute independently (keep a shadow rsp in the front end, dispatch push and pop as offsets to this, and only allocate a new rename register on instructions that explicitly reference rsp), so not using them for spills and restores would likely be slower as well as generating larger code.
Have a link? I looked into it a bit earlier today, and found this comment:
I thought it was in the paper, if not it was from a discussion with the paper’s authors. The version that they upstreamed to LLVM was a subset because everyone was super nervous about needing to support ABI-breaking changes, especially when both Intel and Arm were expected to introduce shadow stack hardware within a few years (this turned out to be much harder to do without completely breaking binary compatibility than either company expected).
-
-
-
-
-
I can’t speak for x86, but on Arm there are instructions that simplify and reduce code for dealing with the stack. If there were two stacks then there would be more instructions in the prologue and epilogue, and generally more bookkeeping needed (and problaby more registers used).
On Cortex-M the stack is handled in hardware for interrupts. Having two stacks there would be a huge penalty.
-
on Arm there are instructions that simplify and reduce code for dealing with the stack. If there were two stacks then there would be more instructions in the prologue and epilogue, and generally more bookkeeping needed (and problaby more registers used)
I don’t know arm. On x86, there also are instructions for dealing with the stack; but the net effect is neutral or positive. (In particular, you no longer need a frame pointer, because the call stack frames have a fixed size, and point to the data stack frames.)
x86 also uses the stack for interrupts, and would work just fine with a scheme using two stacks. Essentially, the cpu briefly pushes some data onto the call stack.
-
-
Some systems make this pretty approachable, so it’s actually been tried, see e.g. https://s3.eurecom.fr/docs/secucode09_francillon.pdf . I remember reading an even more recent paper about it later on, which actually implemented the whole scheme with LLVM, generating code for AMD64, but I can’t find it right now.
-
-
I’m only able to view the archive version, but assuming the main site matches it, this is a very poor page. There is no normalization of the data (-1 and 3000 are given as answers to “How many years have you been using Emacs for?”), the bars give a relative size but no absolute numbers for the answers (how many people said “No” to “Do you use an Email client in Emacs?”? Good question! I guess you have to download the raw data to find out.), and questions like “Can you recall any difficulties you faced when initially learning Emacs?” are presented as a bar chart, which is just completely useless.
Seriously, as someone who answered the survey and is interested, this is borderline insulting. Is having the raw data useful? Sure, and it’s appreciated. What would be much more appreciated is the people running the survey doing an actual analysis instead of leaving it to everyone to do for themselves.
-
What would be much more appreciated is the people running the survey doing an actual analysis
I haven’t really watched it (and a portion of it seems to be about the technical challenges), but that happened at EmacsConf. It would be really good if that link/video was on the survey site.
-
-
hwayne
3 months ago
|
link
| on:
Raspberry Pi brags about hiring surveillance cop, insults and blocks surprised users
I don’t think this is on topic. As the moderation log is fond of saying, “Lobsters is not the torch and pitchfork store.”
-
-
this is a warning about a well-known manufacturer behaving badly.
Personally I find this a useful datum.
Similarly, the drama around Manjaro’s expenses and their financial controller leaving - I don’t care for arguing about it online, but it did feed into my decision to use Mint rather than Manjaro on my recent gaming system reinstallation.
-
-
The title is clearly informative and 100% tech related. It is a really useful post.
Note that the discussion here is civil and focused. People are discussing what it means to hire a surveillance cop in such a company, with pros and cons.
Lobste.rs cannot be a buble “tech without politics” because the tech itself is politic and influencing human politic more than ever before. It would be like talking about cars without talking about drivers and effect on the environment.
-
Seconded. This is not on topic and is not useful.
-
-
Beware that -fpic is not the same as -fPIC. Apparently, -fPIC always works but may result in a few nanoseconds of slowdown, or something.
It’s because of the size limit of the global offset table (GOT) for the target architecture. See the -fpic and -fPIC documentation in GCC.
The StackOverflow answer linked is… meh.
-
I did not see a link to Doug Zongker’s classic paper and presentation.
-
Ok I just read the paper and the link I posted is clearly derivative as well as somewhat reductionist. Compared to the original work done by Zongker, this is a mere shadow. Also watched the talk and found the Q&A to really be something to chew on.
-
-
I have flagged all of them as off-topic. As for why they have not been removed I can’t say since I am not a moderator. I have my say with the flags.
To answer your question, I think many submissions about social media are off-topic, but they must be judged on a case by case basis.
-
I wrote the “Three things to like about the Fediverse”.
Some say it is low quality because it only contains three bullet points. But it took me quite a while to distill the essence of what is good about the Fediverse down to what I consider the three main points.
The reason I posted it here is that all three are benefits for developers.
Owning your identity like you own your domain is something easy for developers. Not so easy for regular users. Although that will probably change over time.
Fully customizing your experience can only be done by developers. As it means you have to customize the code of your instance.
Building cool stuff on top of it is also something that can only be done by developers. As it means to build new software.
-
The three “main points” are devoid of any meaningful content, personally:
- Do you “own” a domain? You’re registered as the owner of a domain, but it’s not really ownership, it’s a lease from IANA or whoever. So what does it actually mean from a technical perspective to “own” your federated identity? There is no knowledge gained from reading this bullet point.
- “Fundamentally open” would be cited as weasel words on Wikipedia. What’s open? You don’t need a FOSS instance to have a federated instance. So the ActivityPub protocol is open? That’s great, but ActivityPub is a standardised protocol - “customise your experience” doesn’t particularly mean much in regards to that. It’s a point that’s been distilled of all information.
- I guess you can “build cool stuff” on top of anything with a big enough hammer, but on ActivityPub/Mastodon/Pleroma that’s fair. This again though is a point distilled of all information, there’s nothing you learn, nothing one gains from reading it.
Hope this gives some perspective on why people, or at least I, would have downvoted your submission or considered it off-topic (lacking technical content). It’s nothing personal, I’m sure your tweets are great and you have technical information, technical knowledge etc. you could share in the future.
-
There is a lot to unpack here. Let me start with the first point:
You are always at the mercy of some infrastructure providers. That is why in my Tweet, I wrote “You can own your identity to the same degree you can own a domain”.
IANA, ICANN, your registrar, browser vendors, operating system vendors .. they all have the power to interfere with how available a specific domain is. But these infrastructure providers are generally orders of magnitude more trustworthy than social networks. How often did you hear that one of these infrastructure providers interfered with a single domain? I can remember almost no such events. On social networks on the other hand, interference with visibility is the norm. Even outright deplatforming is pretty common.
So owning your identity to the same degree you own a domain is a big step forward.
When decentralized domain name systems like .eth become supported, you can own a domain to an even higher degree. By being the only one who knows the secret key that holds the power over your domain. That would cut IANA, ICANN and your registrar out of the loop.
-
How often did you hear that one of these infrastructure providers interfered with a single domain?
It happened to a website which shall not be named just the other day (recency bias? I’d have to look for other examples.) Your identity is now also subject to potential hijacking or squatting. Not having a process you can turn to and recover your stolen identity is a huge step backwards.
Side note: I think it’s a good thing that social networks interfere with visibility of certain content, and federated social media does so in very broad strokes (example). De-platforming and censorship are social debates, and debates not solved or avoided through federation.
-
Can you elaborate on what you mean by potential hijacking or squatting?
-
-
-
-
As for why they have not been removed I can’t say since I am not a moderator.
When I ask whether they should be removed, that is more so a metaphorical question (to everyone but the admin) as to whether the community would appreciate those topics being submitted. I especially wanted to hear from people who had been around for a while, because there was a significant amount of disagreement between users upvoting and flagging the articles. A better question to ask would have been: Should I, and other newcomers like myself, be submitting stories related to social media?
Your answer, as I understand it, is: No, unless there is heavy technical content within. For example, an article describing the logistics behind running a social media database would be okay.
If you have a moment, I’d also like to ask about the nuances of your answer. I’ve also run across a few similar, older posts with no flags:
Do you think these posts are on topic? If so, what makes them different from the posts in my original post?
-
The first is more a community information exchange than anything else, so I’m okay with it. It’s analogous to a bunch of us meeting up and informally exchanging business cards,
The second is off-topic to me. I’d flag it, but it was submitted two years ago so there’s no point. I don’t think this is the place to be discussing the distribution of Mastodon and what it means for online communities.
-
-
-
Always be upgrading!
This is profoundly wasteful and should not be encouraged.
I upgraded my CPU a couple years ago but I made a mistake and bought one that didn’t support ECC RAM because I misread the specs (which is easier to do than one may think). This last month I decided to update the CPU and get the ECC RAM. Turns out upgrading the CPU caused thermal problems and I ended up having to get a cooling unit which I then found did not fit in my case, so I had to get a new case as well. I had to refit the whole setup for my desk as the final kicker.
I probably should have thrown in the towel when the CPU was having thermal problems, but I was stupidly stubborn. Now I’ve spent considerably more than I was hoping for a setup that is only marginally better than it was before. And I have a CPU and RAM that I could sell, but they’re not worth very much and the hassle of selling it seems like a waste of my time.
“Always be upgrading” is a great way to produce a bunch of e-waste that we would be better off without. I hope to not have to update anything for about 7-10 years. If an 8-core home server with 64GB of (ECC) RAM is not enough for home computing needs in that time, we’re probably doing something very wrong.
(Side note: gaming culture has made hardware purchasing a total mess. I hope it fades into the sunset some day.)
-
This is profoundly wasteful and should not be encouraged.
Agreed. To be clear - the “always be upgrading” was meant as a light joke (and a reference to learning as a form of self-upgrade) to wrap up the article on a positive note. :-)
I think of upgradeability as something good, that actually reduces waste, but not something we should be doing all the time. E.g. I’d normally do a CPU upgrade every 4-5 years, but sadly no motherboards have a lifespan that long.
-
-
It’s surprising that AMD would make that mistake given their history. They gained a lot of market share during the era when they supported ‘super 7’ (socket 7 with a few minor tweaks) for CPUs from 133-450MHz, with the same RAM (though you wanted to upgrade to a faster clock ideally), while Intel was pushing everyone to Slot 1 and RAMBUS memory.
-
-
Fair point about Intel. I honestly don’t get why they need new sockets every couple of years. I was definitely very disappointed when AM5 was announced, when I originally expected that Zen 3 would be targeting AM4. And now that AM5 doesn’t support DDR4, changing the CPU means changing the MB + the CPU + RAM, which is almost a new PC. At least they said that all the MB dimensions are exactly the same, so coolers for AM4 would fit fine AM5.
I do think the main reason for the constant Platform upgrades is to appease the vendors of MBs, RAM, etc - they want to sell something all the time, not every 5 years. There are many players in the computer hardware world and everyone wants their cut.
-
-
-
I just built a gaming computer for my brother to last 10+ years. Planned upgrade of CPU in ~5 years, whenever the last AM5 CPU is released. GPU as needed, whenever prices are good. Every other part of the machine I picked to last through those upgrades. Always plan for upgrades to minimize e-waste. Few gaming PCs live 10+ years for exactly the reason you describe.
-
That’s a solid plan, hopefully the last AM5 cheap won’t be released 2 years from now. I guess I’ll stick with my current CPU for a couple of years more, and then I’ll evaluate my options. I still have high hopes for Intel 4 and Meteor Lake. I love AMD, but I really want Intel to get their act together and build something great again.
Btw, AMD did make the vague announcement that they “are going to support AM4” for many years to come, whatever this means.
-
-
-
-
Perhaps Rust should just take existing references and put them in a “Rust Standard.pdf” document with a note that anything not here is implementation-defined. It doesn’t have to be 100% comprehensive. C barely says what happens when you add two
ints, and ISO OOXML got away with things like “render like word95” without further elaboration.-
Yeah, this point about Rust not having a “specification” is getting tiresome. Very few languages have actual formal specifications with operational semantics that govern how they should work. SML is the only generally useful one I can think of.
From the article:
While we do have a reference that explains what features are stable and many of the guarantees of the language, it is not a complete specification.
What does the author feel is missing? There are no concrete examples, just a general statement.
I like pcwaltons approach here, which is basically just to rename the reference to “The Rust Specification” and then get people to shut up.
-
-
Thank you, those are indeed missing.
-
-
-
I don’t agree with pcwalton fully here, particularly having looked at the reference from the perspective of someone in need of a specification (for Rust in safety critical). The reference is lacking both in content and in an important feature: traceability - it is hard to differentiate features in it that can be traced as requirements. Yes, the specification that we ended up writing is based on the Reference - it’s a great document to start with. https://spec.ferrocene.dev/general.html#general
By and large, too much of this discussion is controlled a) by a poor understanding that specifications can be a useful communication document and don’t need to be boring to read and b) seeing specification efforts through the experience of the C/C++ standardisation methodologies.
-
Formal operational semantics of JavaScript, tested against test262 test suite, also exists: https://jscert.org/
-
First of all, wtf?
Top South Africa’s Top No Deposit Casinos. If you want to find some of the best online casinos that South Africa has to offer, where you can take advantage of a juicy no deposit bonus code, then you’re in the right place.
Secondly, there’s a variety of efforts to define similar formal semantics for Rust, just like CompCert exists for C. I think that’s beside the point: Those efforts are not what define the language, they are ex post efforts to make sense of whatever defines the language. In the case of JavaScript this is the defining specification.
-
-
-
and put them in a “Rust Standard.pdf” document
I agree, but please we need to stop with the whole obsession with PDF documents for tech documentation. They’re just old-school and awkward to read on different devices. We invented hypertext documents for a reason, let’s use them! No one is printing off specifications and reading them on a couch by the fire anymore.
I feel like organisations/people choose PDFs to give their writing some kind of feeling of superiority, like how all the crypto
scamsprojects release a wHiTePaPeR which is most of the time just a documentation web page printed into a PDF file.-
They’re just old-school and awkward to read on different devices.
As someone who is looking at hardware documentation, ABI documentation, and various other standards a lot of the time, I still prefer PDFs because I don’t get variety in presentation. Figures look correct, things are generally aligned properly, and they are easier to share across internal networks. If I’m going to get a standards document, I don’t want it to be dependent on network access, nor do I want it to be a bundle of different files. Documentation in PDF form is almost always a single file. This makes search across the entire document simple. Also, if you do need to print parts of them (yes, it happens), the output will almost certainly match the display.
Hyperlinking in a PDF has worked for a long time, and any viewer I’ve used in the past 20 years supports such navigation.
PDFs are awkward to read on some devices, but they are still used because they are predictable and are more permanent. It has nothing to do with “a feeling of superiority” and more to do with online documentation constantly shifting.
-
If I’m going to get a standards document, I don’t want it to be dependent on network access, nor do I want it to be a bundle of different files.
EPUB is almost always a better choice than PDF these days. Yes, presentation can vary, but that’s a legitimate trade-off. PDFs often aren’t readable on anything where the screen won’t fit a letter-sized page in portrait orientation; with an EPUB you get readability on any device, in a single file, without network access being required. I admit that you lose things from PDF (predictable layout; screen layout being identical to print layout), but I think the trade-offs are usually worth it.
-
It’s alway a pain for me to read EPUBs on desktop. I never got around to finding a client or setup which I either like or “just works” and has sensible defaults. Where as decent, built-in PDFs clients are often right there. (A part of may be I have never been motivated to dive down the rabbit hole when I can just lean on my mobile clients)
-
I feel the same about PDF on mobile, though.
For desktop, the easiest thing is to install a browser extension for EPUBs. On Linux and similar, Foliate is the best “just works” reader. I don’t know about MacOS and Windows.
-
-
I never got around to finding a client or setup which I either like or “just works” and has sensible defaults.
Seconded. I’ve tried a few different ones and the display has been hideous. And for some reason navigation was a mess.
-
-
-
-
-
Actually the people that read entire specifications are exactly the kind of people that print them off and read them on a couch by the fire. I certainly do (well, except for the fire - that’s not recommended for improving air quality in a densely populated city!).
(Though I still agree with your point, adding a legible print view to a hypertext document is much easier than the inverse)
-
-
-
It doesn’t define how the sign bit is stored. It doesn’t define how it overflows. It doesn’t dictate a specific size, only a range of sizes with details left up to the vendors. The Rust language specifies all of these things more precisely.
The C spec has a lot to say, but leaves a lot of things vague and vendor specific. In C you aren’t even supposed to expect bytes to have 8 bits.
-
But that’s not a lack of detail in the spec, it’s an explicit decision not to specify certain things in order support a wider range of hardware without affecting performance (for example). I don’t think it means the C standards are less deserving of being called standards or specifications than the Rust reference, do you?
One might also ask why Rust decided to call it a reference and not a spec or standard.
-
I’m not saying it’s not a standard, just that it barely defines what
intaddition is. Rust has a tendency to go for perfectionism, but that’s not necessary. Rust could also make an explicit decision to leave large “implementation-specific” gaps and still call it a spec. Or go the MS OOXML route and get ISO rubber-stamp that whatever the existing implementation does is the standard.-
I’m not saying it’s not a standard, just that it barely defines what int addition is.
Then I don’t see the relevance. Are you saying the Rust reference gets points towards being considered a standard, because it specifies things that are deliberately unspecified in another language that has a standard?
Rust could also make an explicit decision to leave large “implementation-specific” gaps and still call it a spec.
People would make fun of it if the only reason for the implementation-specific gaps was laziness in documentation.
-
-
-
-
-
-
I don’t know LLVM’s register allocator, nor do I know GCC’s all that well, but this kind of register allocation is very specific. Straight line code for an entire function with a lot of computation isn’t all that common. Specializing the register allocator to deal with this is probably not worth the time.
Also, it wasn’t clear to me that the comparison with Clang/LLVM and GCC is all that fair because the SSRA doesn’t appear to be taking the calling convention into account. In the example
r12 = INPUT0() r2 = MUL_IMM(r12)if
MUL_IMMis a function, then the argument has to be passed in r0. I didn’t see anything about that in the description of the algorithm or the code. Maybe I missed it.If
MUL_IMMis not a function, then the comparison is not a fair one for the same reason: LLVM and GCC are bound by the calling convention of the ABI.-
Since the author mentions LuaJIT uses reverse linear scan too, I guess the implication is that the same concept can be extended to support more complicated control flow as well. The linked article does not go into a lot of detail, but it says this:
In LuaJIT, the IR maintains its SSA form - there is only a single definition of a value. This means that when iterating in reverse order, computing the live range becomes trivial. When we first encounter a use of a value, then by definition that is the last use. And when we encounter a definition, that is the only and single definition, and we can release the register. So there’s no need to compute the live range in advance of allocation.
Furthermore, rather than merging the values of multiple branches into the same live range, each value on either side becomes an individual live range. As a result, the live range of a value never has a hole, further simplifying code.
-
-
-
My understanding is that there are no calls here. It is for code without any jumps or branches. Calls are a kind of jumps.
That was my understanding as well, in which case the comparison to LLVM and GCC is invalid since that is nothing but jumps.
-
-
Agreed with @imode: this is not on topic.