But you cannot allow it to change because your users are relying on the existing behavior.
795 karma · joined September 4, 2013
But you cannot allow it to change because your users are relying on the existing behavior.
Why else do you think so many distributions switched?
Yes, the resistance is noisy and stubborn Unix neckbeards. Not even Unix, since every other Unix had something similar to systemd already. LINUX neckbeards.
Everyone forgets or tries to ignore that text files ARE A BINARY FORMAT. It is encoded in 7-bit ASCII with records delimited by 0x0a bytes.
Corruption tends to be missing data, and so the reader has to jump ahead to find the next synchronization byte, aka 0x0a. This also leads to log parsers producing complete trash as they try to parse a line that has a new timestamp right in the middle of it.
Or there's a 4K block containing some text and then padded to the end with 0x00 bytes. And then the log continues adding more after reboot. Again, that's fixed by ignoring data until the next non-zero byte and/or 0x0a byte. This problem makes it really obvious that text logs are binary files.
See the format definition at https://www.freedesktop.org/wiki/Software/systemd/journal-fi...
And here, this isn't perfect but if you had to hack out the text with no journalctl available you could try this:
grep -a -z 'SYSLOG_TIMESTAMP=\|MESSAGE=' /var/log/journal/69d27b356a94476da859461d3a3bc6fd/system@4fd7dfdde574402786d1a1ab2575f8fb-0000000001fc01f1-0005c59a802abcff.journal | sed -e 's/SYSLOG_TIMESTAMP=\|MESSAGE=/\n&/g'
I booted up an old Windows XP box about two years ago before recycling it. It took almost TWO MINUTES to finish booting to the desktop. Some kind of fairly standard 500 GB Western Digital Blue drive. No, I don't know if it had ever been defragmented or had its TEMP files cleared or had old driver modules removed... It was just slow.
I found a registry key that tells Windows to force stop apps that block shutdown. I may lose an unsaved document once in a while but I would have lost it anyway, and I am pretty good about saving things when necessary.
HKEY_CURRENT_USER\Control Panel\Desktop AutoEndTasks REG_SZ 1
If you are doing a lot of waiting look into getting an SSD for your boot drive.
Or you're running some kind of corporate security product that is going to a remote server for "Mother, may I launch this?" on every EXE and DLL.
I like having options that can be anonymous, don't require banks, immune to government influence, and even completely outside any law. Because laws are not always moral and should be ignored and evaded.
That's freedom. Having it is worth the significant amount of problems that come along with it.
See windbg also.
No. Code optimization is a series of logic proofs. It is like playing Minesweeper. If a revealed square has 1 neighboring mine and a count of 1, then you know that all 7 other squares are safe. In other Minesweeper situations you make a proof that is much more complex and allows you to clear squares many steps away from a revealed mine. If you make a false assumption of where a mine is, via a faulty proof, then you explode.
The compiler is exactly like that. "If there is only one possible code path through this function, then I can assume the range of inputs to this function, then I can assume which function generated those inputs..."
You can see how the compiler's optimization proof goes "back in time" proving further facts about the program's valid behavior.
If the only valid array indexes are 0 and 1 then the only valid values used to compute those indexes are those values that produce 0 and 1.
This isn't even program execution. In many cases the code is collapsed into precomputed results which is why code benchmarking is complicated and not for beginners. Many naive benchmark programs collapse 500 lines of code and loops into "xor eax,eax; ret;" A series of putchar, printf and puts calls can be reduced to a single fwrite and a malloc/free pair can be replaced with an implicit stack alloca because all Standard Library functions are known and defined and there is no need to actually call them as written.
- Never GC via using object pools. This code is nastier than C++ because Java is not intended to be used this way.
- GC whenever needed randomly. The game will just pause occasionally. Very annoying as a player.
- Write the actual game in C++. Make a few JNI calls here and there. On feature phones I only remember this being possible for some vendor apps.
If it does use up most of the low orbit space it is because SpaceX is the only company that is even capable of launching that many satellites and making money on it. Until there is another challenger there is zero point in complaining, because competition is not even an option.
Since it is low orbit it is self limiting problem. Any low orbit satellite has a limited lifetime of a few years without power.
I find it equally ridiculous to try to outlaw software radio that might listen to "unapproved" radio bands, or listening to clear-text WiFi, baby monitors and cell phones.
It's almost as stupid as people who would want brain implant computers to implement DRM so people can't record and share their own memory of a movie.
Another analogy would be a country of blind people trying to legislate sighted people wearing blindfolds, because all of their privacy fences have huge holes in them.
Technology improves people's abilities. Adapt.
I remember how I had to solve a pile of thread bugs in a C++ project by changing string assignments into iterator constructors which would bypass the GNU CoW reference counter.
They tried, and tried, but never quite succeeded in fixing every single possible race condition with the reference count CoW implementation.
Not really a surprise but something to be aware of.
Memory map a read/write page and after that memory map a no-permissions guard page. Now you can safely use gets() to read a page size string without allowing a buffer overflow.
For the star, from its point of view its mass has not changed at all. So yes fusion still works.
I have a set of Bluetooth Plantronics Backbeat PRO. There is no boom mic, but everyone I have talked to on cell phone with them has said they sound good. Even when I am out for a walk they filter out all the vehicle noise and wind.
The biggest problem I remember now is that when testing your init script it picks up environment variables from your root shell. So, because of that it works when it shouldn't, and realizing what's missing is a big debugging nightmare. The systemd init starts every unit in the same environment.
Another one that resulted in hours of fun fixing it is init scripts happily starting services even when various filesystems failed to mount. Like /var. Getting those particular database files back in sync after the / filesystem filled up was a nightmare.
Systemd has pretty good documentation and I think it is a feature that its users are pushed to read it, rather than hacking out a shell script that doesn't use half the already existing functions because the author never bothered to read RedHat or Debian docs.
They're also often not integrated into whatever environment is in use. Which means the developer has to be sure to save their files, open this other tool, which has often not been updated to new standards, wait for it to load their JAR files or whatever, and then use a ten year old interface to use the "magic".
But remember to compensate latency cycle counts with the faster cycles of higher speed RAM. Often the absolute time in nanoseconds hasn't changed as much as the cycle count numbers make it seem.
As Flash cells start to fail they are replaced by spare. Because of write leveling this is delayed for a while, but then as each cell reaches its 300 or 3,000 writes, they all start to fail.
If you aren't getting "adequate rear I/O" then go looking for a prebuilt Threadripper Pro system with $700 motherboard. There will be plenty of ports. They have to do something with 128 PCIe lanes.
Now that Go defaults to multiple threads it has lost all of that advantage. Goroutine switching and channel send/receive has to apply all of the locking that any multithreaded program has to use.
It can be protected from exploding rockets by berms, concrete, etc. It isn't as if an exploding rocket is a shaped charge; the force of an explosion would go up and out and be easily deflected.
For example, instead of inserting everything into a log table and deleting old entries and needing to vacuum things, use a partitioned table and just DROP entire partitions when they age out. You can summarize them into some kind of summary table before that, of course.
The partitions are good for the summaries too. Instead of doing index scans on the range of dates across a terabyte of logs, it is a full table scan on a partition of a single day or hour.
You can use a separate database for logging but the one time we did that it got weird. We ended up doing reporting scripts that had to first copy tables from the active DB to the logging DB so we could use them to JOIN on some log columns. They weren't huge but if everything had been in the same DB it wouldn't have been needed.
All of the scripts and procedures I know of were custom written for this. I don't know of any good prepackaged Postgres logging configs, but they may be out there.
The TPM can be used to verify that the next boot stage has not been compromised, but it cannot do the first step, so if bad code inserts itself right up front it can lie to the TPM and unlock the security keys under malware control.
From the 480 there was the 580, Vega 56/64/VII, RX 5700 and now the 6800.
From a few random benchmark site checks online the 6800 is over three times faster than a 480.
Admittedly, to actually buy a 6800 series it is probably at least three times the price of a new 480.