Re: VPN?
I believe what was meant was that in this setup, the client device is only allowed to do plaintext comms with the edge device, so if their MEs start chatting, the use of encryption will make it stick out like a sore thumb.
1298 publicly visible posts • joined 1 May 2008
Loved my NC10, even got my ol' mum one (cost was certainly a factor in them days, admittedly: £400 if memory serves). I ran Gentoo on it; apart from upgrade runs taking more than a day (even with a beefier machine's support via distcc), it was a joy to use.
Had its mobo not cooked off after ~4yrs (perhaps unsurprising in light of the above lol) I still could be: I haven't heard any suggestion of Gentoo abandoning x86 yet, as one might expect given its unique proclivities. Even if they formally renounced it, they'd still be providing basically everything you'd need to go it alone as standard.
>The real reason is: Wayland, by design, does not let the compositor choose where a window appears.
Well this is not correct at all so, good start. Wayland (the protocol) does not have a say at all, unlike in the X11 model. It's actually left *entirely* up to the compositor. *Not* the apps themselves, which is the cause of the bother, because apps have been used to putting their windows where they want. And yes, funnily enough, that doesn't wash on platforms outside the conventional desktop model where your window is not necessarily a rectangle somewhere within another rectangle.
What's intended is that it be the user, via the compositor, that decides where windows go. Apps being opinionated about this themselves is what got the chop (although, as mentioned, there are mechanisms for them to make polite requests to the user/compositor in that regard).
The compositor can and should provide tooling to put the user in control; in KDE this is called KWin rules, and they have been around since long before Wayland and are building on a rich vein of knowledge built-up over time on how to wrangle multifarious windows by the identifying info they provide through X11, and now through Wayland (Wayland has had further work recently to improve how windows are defined to make this capability more controllable).
As for the "pile of windows" problem, no denying this has been a pain point. There is now a session-restore protocol recently finalised for managing this, but it took serious blood and tears to get it there and the bikeshedding it endured was certainly not one of Wayland's finest hours. Worse yet (in the eyes of many app developers, I should imagine) - getting your windows put back where they were when you restart is no longer something apps can simply rely on the X11 environment to do for them; it requires them to write code to buy into the aforementioned protocol, so that what they want done is understood with as little ambiguity as possible. (X11 DEs had this issue too; they just spent long years learning the quirks and finding reasonable solutions.)
KDE devs have commented that that buy-in will likely take years, and some apps will never bother. I hesitate to exceed their optimism, but I do think that before long the needed code will have the status of well-known, drop-in boilerplate that takes negligible effort for an app to implement. Toolkits can likely play a part too. I think the adoption curve will be very slow for a spell, then very fast until it gets as good as it's gonna get.
So that's where it's at. I know it won't be sufficient or satisfactory for a lot of people, but surprisingly it seems like neither you nor the august commentariat in these parts seem to have, or be willing to share for whatever reason, the full picture, so I thought I'd do my best.
LibO is what made me turn to flatpak too. I'm on Gentoo and LibO would be the single biggest compiling task on my whole system, well ahead of gcc, llvm/clang etc. On my old i686 laptop it was likely not even doable due to RAM requirements of the build, and even on my late-'10s Thinkpad it would likely be a >24hr slog.
Gentoo appreciate this and always provided binary packages of LibO (and OO.o before that), but they are notoriously temperamental due to DLL hell. Some of the libs it uses are antisocially ABI-unstable (side-eyes harfbuzz, and I believe poppler used to be an offender too) to the extent that not only are you lucky if your system state at any given time satisfies the conditions for libreoffice-bin to be installed in the first place; once you manage it, its presence will often make it all but impossible to upgrade the rest of your system because those dependencies conflict with those of other key components. AAARGH. There has been a stickied thread about this in the Gentoo forum for ~35% of the time I've been alive.
I threw in the towel and went AppImage first, but those can still be prey to the same DLL-hell issues depending what libs the packager decides to leave the host system to supply. I forget which one it was that broke, but it taught me that, as Henry Jones Snr put it, "Our situation has not improved."
And so, reluctantly, I turned to flatpak as the Last Chance Saloon. I don't like the disk cost, but it works, integrates and updates with zero pain other than that. Like many here I'm fortunate in not requiring to use an "office" suite very often in my duties, but when I need it, I *need* it.
So if this comes to pass, systemd will be the next shit sandwich I have to choke down. I've used it; I don't hate it; I just don't like it so much better than OpenRC that I relish the task of migrating my running system from one to the other, purely for the sake of that seldom-used "office" suite, and purely because some library developers insist on moving fast and breaking things all.the.ruddy.time. The latter is where my ire tends to be directed, and I'd honestly rather apps progressed more slowly/lived without certain features than make use of such antisocial libs. Gah.
Alternative Answer: It requires a significant amount of novel code to be written for both UI and backend, and (1) no active developer has considered it high priority and (2) few users are clamouring for it. Both largely due to the fact that Sync exists, is pretty good, and requires only an email address from the user (which can always be a throwaway/dedicated one) and that's all the data Mozilla get because all your data is encrypted before it leaves your device.
The Sync server stack is open-source so you are welcome to review it for backdoors if you can be arsed. I used to be like you and self-hosted an instance myself, but after a while I ceased to see the point in doing so given the above.
There is much to dislike about Mozilla but in my book Sync is one of their finest achievements. It has solved a ton of inconveniences for myself and the unlucky sods who look to me for support in such matters. Besides, if I were you I'd be more worried about Google reading the export file off your phone the moment you exported it ;)
As you already need root to load modules, the attacker could also reverse your sysctl setting (and nobble whatever monitoring you put in place). Probably requires the attacker be a problem-solving meatsack and not just a dumb payload, but I say that as someone who doesn't closely follow AI's capabilities.
As another Gentooer I also build-in bespoke to the host, but I'll assume Red Hat would not support that sort of shenanigans under warranty. Also the workaround for this vuln does illustrate that modules can be good in this scenario when they're something the host can survive without (at least temporarily). Build a monolith and you lose that wiggle-room.
I mean, 1984 was over 4 decades ago now. It's closer in time to when the book was written than it is to the present.
By most assessments Orwell under-shot by at least a decade (at least inasmuch as where his predictions met Western societies), so I'd like to think he'd have been a bit relieved about that. I'm not much of a scholar and it's a while since I read the book, so I can't tell you what he thought about the further future.
Anyway if you think he's got it bad, what must Arthur C Clarke have gone through before he even snuffed it?
HP has a "bloatware" app for its printers (HPLIP) that contains not one but two CUPS drivers (new, hpcups; old, hpijs). It's OK I guess, the PyQt gui was useful sometimes (although it farms scanning out to xsane). Not been updated to Qt6 though, so being dropped by many distros at this stage (the drivers don't depend on this obv.)
Not needed anyway these days as CUPS (yes, still going strong) handles driverless/IPPAnywhere printing, and whatever the equivalent buzzwords are for scanning, with aplomb on any models that support them (which is anything not antique at this point). I'll say this for smartphone hegemony: it made the printing scene much more ergonomic and largely freed us from driver-hell by ensuring the hardware talks common standards.
Excuse? Fault?!
Bloody Stockholm syndrome, that is. How about let's direct the blamey words at the shitehawks who trouser the premium for "professional" software then turn around and panhandle obnoxiously to stiff the buyer for further (most entirely inappropriate) addons.
Many addons available for this. YMMV as I'm not familiar with what hurdles some sites might put on operation, but I use the top one (the craftily-titled "Authenticator") can screengrab the key when the site puts it in a QR code, or it can be manually entered. The key syncs via Firefox Sync to other devices (desktop; I don't use it on mobile so dunno about that) and the key list can also be exported to text file.
Thanks. I'm struggling to understand what would be a legitimate reason for an external website to be able/allowed to monkey with my router etc via a browser session, but I'm probably a bit sheltered these days.
I note it says rollout is gradual which I think means I don't have it yet as I can't see these entities in the Permissions section. As long as it doesn't affect my ability to login to such devices' _own_ onboard web interfaces, I don't care.
Probably depends what it is you dislike about RPiOS.
If it's the default desktop du jour (labwc this week IIRC), bear in mind that you can install the Lite edition (no desktop) and simply add another DE/WM of your choice. I've done this with KDE on Pi4s and 5s and find it tolerable with 4GB, and quite serviceable with 8GB, just running off the SD card.
My mob have just levelled "up" from MSO 2007/2010 to MSCPsomethingorother365 and in the process I've found it to much more resemble a web app now; complete with ruddy My Account lozenge at top-right and constant pesky extraneous popups and interstitials occurring where and when one desires them least.
The extent to which the "whole team can collaborate" seems a bit limited by it being a single-user app confined to a single workstation.
Maybe I'm misunderstanding things about the existing Collabora offering, but I thought the main point was that with the documents being hosted on the server, it allowed for _simultaneous_ collaboration between multiple users. Maybe concurrent editing wasn't part of the spec (I'm not gonna go diving to find out) but just the fact of shared, mediated access to a central repository of documents would have made that a boon for collaborative work.
Does this new version actually support multiple clients, like over the LAN? If so, then I suppose as a version that's easy to install on the desktop without needing to figure out the rest of the server stack to host it, that could be handy. But if it's just the server in a box, for one local user, seems a bit daft when there's LO to provide the same thing.
Or is what they've done with the UI just so desirable that it still beats out OG LO even with this overwrought architecture?
>I do worry that going forward the choice of Linux distros for servers may be constrained by whether you can rip out Wayland and install x.org rather than by whether the rest of yhe system is up to snuff.
But as you alluded, the X server is not on the server where the app is to be run, so the server distro does not need it anyway. The workstation distro may not have an Xorg server to run, but will likely have Xwayland, so you can still do ssh -X (or -Y). I can't see Xwayland going away for a long time, if ever.
The apps to be run on the server can be run with their UI on your workstation whether they (or more likely the toolkit they're built on) support X11, Wayland or both. If X11, use ssh -{X,Y} to Xwayland. If Wayland, use Waypipe, which is functionally the same thing as far as I can see.
I always thought running GUI apps on servers was considered baaad, anyway. When I was coming up the gold standard of server GUIs was Webmin (which I just checked out and is looking a lot slicker than it did in 2004).
The OP refers to scrcpy which is a cross-platform app that leverages the Android debugging interface (adb) to mirror the device's screen and provide remote input. Remote desktop for your phone, basically. Works over wifi as well as USB, although not quite as responsive obviously. Can also do other things supported by the debugging API such as passing-through the device's camera(s).
I see what you mean. I assumed they were assigning via their own DHCP server because that's how I do it (not because I have any devices that can't do static IP, but because some of them are damn fiddly to do so -- the verkakte touchscreen printer and the net radio with only a jog-dial for text entry spring to mind -- and it means the assignments are kept in one place so I can look them up when I forget them).
It might differ between manufacturer UIs, but in my last two Samsungs, the static IP UI only covered IPv4. No way of specifying a v6 address.
What a silly dance. Crafting a thumbdrive that behaves in that way took some effort (and presumably cost) over just whacking it on the smallest commodity whitebox drives you can scape up off Aliexpress. Why?
This may be controversial but I don't think in today's world it's a grave sin for an OEM to say: "We don't wanna generate more [practically] single-use e-waste, just go download $driver from $link on another machine before installing." How often, really, is that not feasible?
That's nifty an'all, but to what actual machines do each of those inscrutable addresses belong?
Predictable naming/addressing of local hosts (DHCP+local DNS) was the piece of the puzzle I failed to solve when I had a stab at IPv6. With one machine running dnsmasq, I can have each machine's name and IP mapped to its MAC in a centralised DB meaning all hosts can reliably contact each other by name. (Also any host that's not supposed to be there either can be denied access or will stick out like a sore thumb.)
The closest I got was DHCPv6 but our Android phones did not play ball with this, which I learned is because Google have vetoed it for some reason. Neato.
All that left was Avahi/Zeroconf/Bonjour/whatever (ugh, rather not) or somehow piggybacking the IPv6 DNS resolution on the DHCPv4 config (which maybe dnsmasq can do natively, but I ragequit before I could establish this, plus a solution reliant on dual-stack wouldn't feel ideal).
I feel like there must be an intended way for this to work, but it might be a while before I reacquire the minerals to have another push at it.
Me after the first attempt ------>
This. Been using for some time on our in-house system (not that we need PDF2.0 with any urgency) and when you add the fact that .OD* files can be manipulated quite easily by any server lingo with zip and XML/DOM support, it can be a very capable doc generation platform.
Saved me enough time/money for a few more of these ---->
We really need to come up with a common name for that thing, I keep wondering why people are pausing before they say "menu".
[Though I must admit I have started interpolating it as an exasperated sigh, which seems to stand up well in most contexts so far.]
Yikes, that's ... worse. (Why does GPS even need a week counter anyway?)
I want to be charitable and assume these design decisions are down to self-deprecation/utopianism on the part of the developers: "By the time we need more than that, this old thing will have been replaced by something completely new and better anyway" sort of thing.
Which in turn makes me think those devs were rather green, at least in the ways of the relationship between innovation and money, which has illustrations a lot older than the computing sector.