The WSJ editorial was in response to the flood of mainstream coverage about the administration's announcement yesterday. I knew it was an editorial when I linked it and it should be obvious to anyone who reads it. Is there any question about the facts of the administration's policy statement?
True, but suddenly, after this new questionable paper appears, the current US administration is now considering a ban on gas stoves in all new construction.
X was developed on VAX, 68k, and later SPARC and then x86. VAX and x86 are little-endian, while 68k and SPARC are big-endian. Portability across these platforms was important and this was the inspiration for the RPC (now gRPC) platform-independent external data representation (XDR) standards.
Things were still not perfect with portability even back then. I remember taking a class in OSF Motif where everybody in the class was using SPARC while I was using x86 Linux. The code was somewhat portable between platforms, but many of the arguments to the (Metroworks) Motif library functions needed their endianness swapped in order to work properly on Linux, so the code examples from the course would not run on Linux without modification.
I realize that there may be some performance improvements realized by removing cross-platform compatibility, but I do not believe that the performance gains are worth the loss in platform compatibility. If X.org does this, it will eliminate one of the core reasons for sticking with X vs. Wayland.
I had to click and read the article to see whether CGI in this context was "Computer Generated Imagery" or "Common Gateway Interface". I've always been a fan of simple CGI interfaces. More middle-ware always means more bugs.
Nothing is 100% secure, but I have opted for a high-quality gun/fire safe that's bolted to the foundation of my home (in a gated community), and protected by multiple monitored alarm systems and cameras. The safe has a lot more room than any bank's box would, it's cheaper in the long-run, and IMHO (especially after reading the fine article) more secure. Also, it's got a S&G spin-dial lock that I trust a lot more than any electronic garbage.
Thanks. If run as an unprivileged user, the dd command will not consume ALL of the disk space (so privileged processes will not be disrupted). It will consume up to the free space limit (default 5%) as described here: http://blog.serverbuddies.com/using-tune2fs-to-free-up-disk-...
The zerofree command looks useful, but I don't know how portable it is. The dd method works across many platforms (such as AIX).
I use this all the time. It's a big time saver on multi-core machines (which is pretty much every desktop made in the past 20 years). It's available in all the repos, but not included by default (at least in Ubuntu/Mint). It is most useful for compressing disk images on-the-fly while backing them up to network storage. It's usually a good idea to zero unused space first:
Compressing on the fly can be slower than your network bandwidth depending on your network speed, your processor(s) speed, and the compression level, so you typically tune the compression level (because the other two variables are not so easy to change). Example backup:
(Note that on slower systems the ssh encryption can also slow things down.)
Some sharp people may notice that it's not necessarily a good idea to back up a live system this way because the filesystem is changing while the system runs. It's usually just fine on an unloaded system that uses a journaling filesystem.
I cannot find any reference to this online, but your post reminded me of a similar message to the Russians from the same era. The roof of the Northrop plant in Hawthorne, CA (now SpaceX) had "Yeb Vas" written in some fashion so as to be visible only from the ISR satellites of the day.
I did some development on uVAX in 1989. Wrote a DECWindows app that did monitor & control of a distributed realtime system. DECWindows was slow, so it would get updated every 250ms, while the realtime stuff communicated to a proxy (via 10Mbps DECNet with a custom driver) every 20ms. All of the code was in 'C', but everything aside from the DECWindows stuff was running from ROM on embedded VAXELN.
int
signed
signed int Basic signed integer type. Capable of containing at least the [−32,767, +32,767] range.[3][a]
So a minimum of 16 bits is used for int, but no maximum is specified. Thus, if my C compiler on my 64-bit architecture uses 64 bits for int, this is perfectly allowed by the specification and my answer is correct.