FTP, unless you are using it over TLS (FTPS) transfers authentication information in the clear and transfers files in the clear.
SMB and NFS both can, depending upon implementation and configuration, be set up to do encrypted transport. Note that it is possible to have either doing secure authentication but not secure transport of data.
From a quick search, it looks like at least some Synology NASes can do secure NFS:
Yeah, you can see in the image where one of those was a hit below the waterline there in the Salton Sink:
The lowest point of the sink is 269 ft (82 m) below sea level
I’m afraid that this is probably it for the United States.
It was a brave experiment in democracy and republicanism that was influential on much of the world, though; its cultural and technological contributions will be missed.
On the silver lining side, it looks like the long-sought-after more-direct Northwest Passage between Europe and East Asia will be practical.
For centuries, European explorers, beginning with Christopher Columbus in 1492, sought a navigable passage as a possible trade route to Asia, but were blocked by North, Central, and South America, by ice, or by rough waters (e.g. Tierra del Fuego).
No doubt this will have significant effects on the transit-related economy in Panama.
Well, if you don’t live in the EU, it doesn’t directly matter, other than in your ability to communicate with people in the EU.
If you live in the EU, then I suspect that talking to European political entities like the various Pirate parties, or to EDRi to try and get it legislatively-reverted is probably a step to take a little before killing and dying.
If you live in the EU and it doesn’t get legislatively-reverted and you consider it to be totally unacceptable, well, there are a number of countries in the area that I imagine people can migrate to, like the UK or Switzerland or Norway. I’d probably look into that before the whole killing thing.
Hmm. Do you allow people to VPN in from non-company-controlled laptops? Because I figure that anyone doing work at home is going to be maybe unwittingly having local copies made of data that they’re working with.
The Intel MacBook waking up from hibernation is about 30 seconds to get to the login prompt, 30 seconds for the login prompt to actually work, then 10-15 seconds after entering the password to get to a usable desktop environment with the wifi generally connecting within that window.
Hmm. Yeah, okay, I can see about a minute-and-a-half being obnoxious.
So, the login prompt can probably be dealt with by just having some way to treat the login process specially and paging it in sooner. Like, I can’t believe that it uses all that much memory. If it isn’t an isolated process, make it one.
But that’s with only 8 gigs of ram on this MacBook, the more ram the longer it takes. The 32 gigs of ram in my actual work laptop (ThinkPad P1 11th gen i9) takes about a minute to wake from hibernation, and like 2 minutes for it to fully get situated.
I’m using a 32 gig laptop. But most of that doesn’t get used other than as disk cache, and I believe that normally, Linux isn’t gonna restore the disk cache; it’ll just drop the cache contents. Right now, I’m using 2.3G for actual application usage.
considers
I figure that maybe the desktop shell or whatever Apple calls it these days – going back to classic MacOS, the Finder – probably is more-heavyweight than what I’m using, but I figure that they could maybe do something like temporarily twiddle I/O priority on processes during the de-hibernation process. Like, okay, anything other than the foreground process gets an I/O priority penalty for a period of time. Like, maybe your music player or something is choppy for a few seconds, but whatever you’re directly interacting with should be active more-quickly.
If this is SSD, that seems kinda long, still. Like, it shouldn’t take 2 minutes to move 32GB to SSD.
It looks like I get about 3GBps reading from SSD:
<span style="color:#323232;">$ dd bs=100M iflag=direct if='setup_act_of_war_direct_action_1.06.3_(24183)-1.bin' of=/dev/null
</span><span style="color:#323232;">40+1 records in
</span><span style="color:#323232;">40+1 records out
</span><span style="color:#323232;">4294098942 bytes (4.3 GB, 4.0 GiB) copied, 1.28615 s, 3.3 GB/s
</span><span style="color:#323232;">$
</span>
And that’s doing I/O going through the filesystem layer; I dunno if Macs use a swap file or swap partition these days, but if they have a dedicated partition, they might pull a bit more throughput). So if you figure that in terms of raw I/O performance, it shouldn’t take more than about 10 seconds to fully restore memory contents on a 32GB laptop with comparable SSD performance, even if the OS has to fully-restore the entire contents of the memory. There’s some hardware state restoration that has to happen prior to starting to pull stuff back into memory, but for the memory restoration, that’s the floor. If it’s more than that, then presumably it’s possible to optimize by reprioritizing reads.
So, I guess that there are maybe a couple areas for potential improvement:
If the thing is locked and requires a password or something, you know that the user is gonna have to use the login process before anything else. Get that paged back in as soon as possible. Ditto for the graphics layer, Quartz or whatever Apple has these days. Strip that login process down; maybe separate it from whatever is showing blingy stuff on the login screen. Can have the OS treat it specially so that it’s first in line to come up.
The next goal is to get the stuff that the user needs to be immediately interacting with back into memory. My guess is that that’s probably the launcher and/or task switcher and the foreground process. Might have a limited amount that can be done to strip the launcher/task switcher down. Have all processes other than those few favored processes get a temporary I/O priority penalty.
One wants to keep the I/O system saturated until the system is to a fully-restored state, so that we don’t have to have the latency of waiting for a process to request something to bring it back into memory. So have some process that gets started, runs with I/O priority below all other processes, and just does bulk reads of valid pages from the pagefile (or wherever MacOS stores the hibernation state). Once that thing has completed, the system should be fully-warmed back to pre-hibernation state. That eliminates idle gaps when maybe there’s no reads happening. Maybe restore the disk cache state after that, if that doesn’t happen now, if the reason the system is sluggish is because it’s having to re-warm the cache bit by bit. On my Linux box, it looks like post-restoration, the disk cache is empty, so it’s probably just dropping the disk cache contents (which probably speeds up hibernation, but is gonna mean that the post-hibernation system is gonna have to figure out what it’s sensible to cache).
EDIT: Also, relevant Steve Jobs quote that comes to mind:
Larry Kenyon was the engineer working on the disk driver and file system. Steve came into his cubicle and started to exhort him. “The Macintosh boots too slowly. You’ve got to make it faster!”
Larry started to explain about some of the places where he thought that he could improve things, but Steve wasn’t interested. He continued, “You know, I’ve been thinking about it. How many people are going to be using the Macintosh? A million? No, more than that. In a few years, I bet five million people will be booting up their Macintoshes at least once a day.”
“Well, let’s say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that’s probably dozens of lifetimes. So if you make it boot ten seconds faster, you’ve saved a dozen lives. That’s really worth it, don’t you think?”
We were pretty motivated to make the software go as fast as we could anyway, so I’m not sure if this pitch had much effect, but we thought it was pretty humorous, and we did manage to shave more than ten seconds off the boot time over the next couple of months.
Sure, you’d have to not lay em off, but only the people who are actually making use of their services are paying for them. So users get the “censored” or “non-censored” option.
I don’t really have one specific type of pizza, bounce around a bit.
When I was growing up, the norm for my family was thick crust, pepperoni, black olive. I like that, but I tend to feel that it’s nice to have a bit more going on. That plus onion or chicken or hot sausage can be nice.
I do like Hawaiian, though that does tend to have more moisture than would be my ideal.
So, I don’t use Twitter. But as I can tell, here are some of the the sources of friction:
The rebranding to X threw out brand value.
Policy shifts didn’t make some people – who wanted the other policies, which I understand to generally be more-content-restrictive – happy.
Twitter laid off a bunch of expensive human moderators who were censoring content.
So, speaking personally, I’m pretty hard in favor of speech being permissive. I don’t want someone preventing me from seeing someone’s speech. I want to make those decisions myself.
However, there are people who don’t agree; they’d prefer to have their environment have content moderation.
What the changes did was basically force people into a more-permissive environment, which some did not like.
With the benefit of hindsight, what I think Twitter should have done is the following:
Keep Twitter active.
Start charging for or otherwise monetizing Twitter sufficiently to cover human moderator costs.
Start up X.com. Provide a seamless migration path to X.
Gateway all Twitter content to X.com. Don’t do the reverse (or maybe do so on a limited basis, like having particularly popular content flow back, but filtered or human-curated). Maybe have some mechanism for Twitter users to request that X feeds be gatewayed back to Twitter.
That solves a number of problems:
People who want a place that have censored content have that option. The default is for the environment to remain the same.
People who don’t want heavy moderation can have that, and aren’t having to pay for someone else’s moderation.
If a country wants to ban X (like, most of the regulatory yelling I hear about X seems to be coming from the EU) they can do that. People in the EU can still use Twitter.
It’d even be possible to make other content-filtering variants attached to X, because I guarantee that some countries have different ideas of what they think should be permitted in public discourse.
The brand value doesn’t go away; I’ve seen many people point out that Twitter is a very-recognizable brand.
I suggested that something vaguely similar might be a good idea, back when the EU started passing some of their content restrictions. Didn’t involve the X.com stuff, though; that came later.
Like, the problem here is basically that there are different social norms and regulatory regimes around the world. Trying to create one global identical set of policies is invariably going to make some users and some countries annoyed. But…that’s not really necessary to have at least some level of global intercommunication.
I imagine that most distros probably have a liveboot image, though I haven’t gone looking.
USB drives are maybe slower than your internal SSD drive, but for rescue work or just seeing whether your hardware works, should be fine.
I would expect everything that you listed there to work. The only thing I haven’t heard of on there is that dygma keyboard, and looking at their website, if this is the keyboard in question:
Yes, our configurator software is compatible with macOS, Linux and even Windows.
I mean, I dunno if Logitech puts out trackball software for Linux, but if what you want is macro software or configurable acceleration curves or something, there’s open-source stuff not tied to that particular piece of hardware. And the Steam Deck is running Linux itself.
There’s gonna be a familiarization cost associated with changing an OS. Like, your workflow is gonna change, and there are gonna be things that you know how to do now that you aren’t gonna know how to do in a new environment. But I think that that’s likely going to be the larger impact, rather than “can I use hardware?”
EDIT: Oh, it sounds like the reason that they call it “live install” rather than “liveboot” is because you can use the same image to both just use Linux directly, and can run the installer off the image too.
I have my Linux Thinkpad set up to just go directly to hibernation. If I flip the lid open, by the time I’ve closed up my laptop backpack, stashed it, pulled my seat out, sat down, and scootched up, it’s pretty much up. And if it’s hibernated, then you don’t wind up with a case where you leave it in your bag for a long time, it draws down a bunch of a battery, and next time you open the thing up, maybe away from a plug, you don’t have a big chunk of your battery slorped up.
does some timing
Booting up and responding after a hibernation is a little under 30 seconds.
Doing so after an S3 sleep is a little under 5 seconds.
Now, okay, that’s just the system being back up, and it’s gonna have to broadcast a query, wait for responses from WAPs, associate with a wireless access point and get a DHCP lease before the network’s up, so maybe there’s a little extra time until the thing is fully usable, but still.
I guess…hmm. I guess I can see doing a sleep-with-delayed hibernation for something like the case where someone’s moving between an office and a conference room. Like, wait 5 or 10 minutes, and if it’s still sleeping, then hibernate. What are the defaults?
goes looking
Hmm. Okay, so looks like on Debian, the default is to sleep (suspend) until the battery is down to 5%, then do a hibernate if it hits that critical level. Yeah, I never want to wait that long.
Aight, I’m gonna move from directly hibernating to a 5 minute sleep or 5% battery, whichever first, then hibernate. I guess that’s maybe a good tradeoff for a scenario where a laptop is being frequently closed and opened, but it still shouldn’t result in much extra power consumption.
I mean, Russia doesn’t have a whole lot by way of alternative markets for pipeline natural gas, due to the invasion.
And Russia didn’t negotiate the deal prior to kicking off the war, when they had more leverage.
They kind of set themselves up for not getting very favorable terms.
EDIT: Not to mention drawing down the storage of their last customer and then cutting them off as leverage. That’s gonna impact the expected risks attached to Russian gas.
Do you remember when you could put your Mac to sleep, and when you woke it up a few days later, the battery would barely have dropped? Not now, because your computer never really sleeps anymore.
I assume that the Mac has some kind of hibernation function, and that that will reduce the battery drop to effectively zero.
Now the Lord was with Judah, and they took possession of the hill country; but they could not drive out the inhabitants of the valley, because they had iron chariots.
Dealing with vehicles has never really been a terribly strong point for God.