raggi

21 ms·

331.
by raggi 3y ago
systemd’s efforts in the boot path are very welcome, they’re much better. Sadly as others have noted, a great many distros are still using grub. To clarify a bit too, as it seems it may not have been clear: grub was never run or installed i
332.
by raggi 3y ago
Grubs install process is a complete disaster. I went to use it to boot Fuchsia on bios systems at one point, when Zircon still supported multiboot chaining. The "install" scripts and so on are all horribly broken, and extremely ba
333.
by raggi 3y ago
Can you point to an URL where a system has a documented or implemented configuration that correlates traffic to log entries in a manner that can be alarmed on without just going off all the time? Junk packets to port 22 arrive all the time.
334.
by raggi 3y ago
I see, it's slight and deliberate misrepresentation/under-presentation. Google did talk about it in https://blog.google/products/news/california-journalism-pres... Specifically: To prepare for possib
335.
by raggi 3y ago
Does anyone have a source or confirmation that Google is doing what the article says? If I search for journalism bill I get the politico article, and san francisco chronicle in the top stories list.
336.
Hytera sanctioned, can not engage in radio business in the USA [pdf](hytera.com)
2 points by raggi 3y ago|0 comments
337.
by raggi 3y ago
Software fault. Even if they tried to do the right thing a barcode scanner has to be used while the screen and paper are not visible. We should have baseline expectations for UX thinking which are higher than this standard.
338.
by raggi 3y ago
No the problem is that the software bugs regularly enough that conflicts are disregarded
339.
by raggi 3y ago
Occupation lights are typically driven by the lock, not by some sensor that would detect a bodily presence
340.
by raggi 3y ago
If you don't have an RTC I'd recommend having a tlsdate with some bounding heuristics to prevent extreme clock fixation from a mitm. You can relatively cheaply hit a large number of public servers that are likely to have good time
341.
by raggi 3y ago
Java behavior is in general/abstract similar to .net - there are types & APIs to pin memeory for ffi and aliasing use cases but normal references are abstracted enabling the gc to perform compaction/moves for non pinned object
342.
by raggi 3y ago
In order to move objects you need to stop the world and update everything that will ever point to them: pointers, pointer aliases, arithmetic bases, arithmetic offsets. This quickly becomes intractable. It's not strictly speaking just
343.
by raggi 3y ago
Yup, and exposing pointers in a gc language was a mistake as it blocks this. It limits (efficient) applications to small deployments
344.
by raggi 3y ago
start here: https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begi...
345.
by raggi 3y ago
yup, it's bad, and even if you "do everything right" minimization wise, if you're still using the heap then eventually fragmentation will come for you too
346.
by raggi 3y ago
this does not eliminate write contention, it just moves a bunch of the problem into the application as now you have to resolve conflicts yourself
347.
by raggi 3y ago
(Tailscalar here) I identified a big chunk of the background drain on iPhone recently, and so drain just for being on in the background is much reduced now. There’s still more to do, and we still end up with accounting for dns if you force
348.
by raggi 3y ago
Pick a linearization strategy and walk it, this isn’t all that different from the “confusing history problem”, which is largely solved by —topo-order which is not the default because it’s slower
349.
by raggi 3y ago
A merge only workflow with replacement log tools to only show merge commits, and a better solution for CI and web presentation would basically fix git. People have a ton of opinions on merge commits but they stem from very few real issues:
350.
by raggi 3y ago
This appears to suffer from the same mistake as many of these things do in this space: it focuses on making it really easy to run lots of software, but has a very poor story when it comes to making the data and time you put in safe across u
351.
by raggi 3y ago
The buffered read didn’t do that, it used the default buffered reader implementation. IIRC that implementation currently defaults to 8kb buffer windows which is a little too small to be efficient enough for high throughput, but substantiall
352.
by raggi 3y ago
all true, as I said in another fork of the thread, this comes down to part of what humans will still be valuable for in this loop: distilling poor requirements into better requirements.
353.
by raggi 3y ago
good catch. feeding it the error output of rustc it then produces: use std::fs::File; use std::io::{self, Read}; fn read_file_character_by_character(path: &str) -> io::Result<()> { let mut file = File::op
354.
by raggi 3y ago
here's what it does if i feed your nit pick into it verbatim: use std::fs::File; use std::io::{self, Read}; use std::str::from_utf8; fn read_file_character_by_character(path: &str) -> io::Result<()> {
355.
by raggi 3y ago
fwiw, the benchmark that matters really has nothing to do with authoring code. the typing of code is the easy part even though it's a part a lot of folks are somewhat addicted to. the things which have far more value are applying value
356.
by raggi 3y ago
it does an ok job with this task: use std::fs::File; use std::io::{self, BufReader, Read}; fn read_file_character_by_character(path: &str) -> io::Result<()> { // Open the file in read-only mode.
357.
by raggi 3y ago
Yeah, perhaps something akin to an OSS variant of virustotal's multi-vendor analysis. I'm still not sure it would catch this, but as you say, raising the bar isn't something we tend to regret.
358.
by raggi 3y ago
Ah, thank you for the correction!
359.
by raggi 3y ago
There is one possible time pressure involved, which is that libsystemd dropped the liblzma dependency
360.
by raggi 3y ago
Think whatever you shall about systemd of course, but please stop with the blind belief mud slinging: - systemd didn't create the patch to include libsystemd, distros did - current systemd versions already remove liblzma from the

More ›