Posts by Havin_it 1276 publicly visible posts • joined 1 May 2008
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.
What intrigues me about that is that there might quite well have have been, at the time, at least the odd tenured prof still stalking around the campus who was actually born before that lower-bound. Good job it didn't roll straight out into payroll.
We dwell a lot on the future wrt this problem, and how the decision wasn't very forward-looking, but it's equally tickling/embarrassing that nobody considered any applications needing to manage times even at the beginning of their own century.
I think supporting Wayland-only apps in X11 desktops falls outside the scope of what Wayback is looking to provide. Giving distros a pathway to be able to drop the Xorg server without orphaning some treasured X11-only DEs is the name of the game; throwing those DEs a further lifeline of support for apps that have left X11-native behind is manifestly not.
To their credit*, the XLibre mob do seem to be motivated to address this, with discussion of integrating an embryonic tool called 12to11, which appears to be akin to a "reverse Xwayland":
https://git.linuxping.win/12to11/12to11
[*Albeit that the stated motives range from the practical utilitarian to a desire to "own" any app devs who've had the temerity to abandon native X11 support. That place is giving my popcorn dealer aneurysms.]
>M$'s protocols bonfire is taking file types for the old Word and Excel (and presumably PowerPoint and Access?) and junking them, about the same month as W10 EOL.
I can't find any citation for this. I think it's incorrect. Some older apps are being EOL'd but what you allege is not mentioned anywhere.
Will be interesting to see the spreadsheet of which rolling distros have taken this approach.
No surprise to me that Gentoo did not. For the new kwin-x11 package to fail to be built, you would need to have disabled the "X" USE-flag either globally (which would be rather bold* as you wouldn't even get Xwayland) or for the kde-plasma/plasma-login-sessions ebuild (and kde-plasma/plasma-meta, if you are using that).
*Of course if you are an iconoclast about it, Gentoo has allowed for X to be purged more comprehensively than most competitors for a while already.
So ... what you're concerned about is the client machine's X server being compromised/naughty and then compromising the server through the X client app (whatever it may be)?
1. This is a pretty damn skinny attack vector considering how many people actually use X forwarding (let alone on servers of any value/interest), plus requiring a chain of at least 3 exploits to pwn the server (machine)
2. I'd say it falls within the standard purview of whoever admins the server (machine) to sandbox or otherwise lockdown any client apps that might be run on it to an extent that is satisfactory for that server's particular security needs. This applies equally to Xeyes run in a forwarded X session as it does to nano run in an SSH session, as far as I see it.
The whole client-on-the-server/server-on-the-client element of this topic still makes my brain hurt a bit after 20some years so apologies if I've misunderstood your thrust here.
I don't think there was any suggestion of the browser being able to override OS-level policy, was there?
And if it is just the "nag factor" of the browser asking for something the OS won't grant it anyway: surely the browser has a "global deny all" setting? I know Firefox does.
Can't speak for Graham and am a mere 500-odd tab case myself, but:
1. There is arguably some pathology in hoarding so many, I'll allow. Maybe nothing worse than laziness in not getting around to spring-cleaning a few of them more often though.
2. They can be very much like bookmarks, but with less effort to maintain: Ctrl+D or more painstakingly select which subfolder to file it in, vs it's already right there; Navigate to bookmark, right-click, delete, vs Ctrl+W bye-bye forever. (Although Recently Closed Tabs means it needn't be forever if you made a booboo, unlike deleting a bookmark.)
3. I like the chronology of recent (and yes not-so-recent) events the linear accumulation of tabs presents.
4. The scroll position on the page (and some other bits of "live" state) persist even after a reboot. That can be very handy.
I actually do save the whole lot as a folder of bookmarks once in a while, but only out of paranoia in case I come a cropper like our poor OP here, and touch wood I have not had any such issue in quite some time.
As several above have opined, the motives for the move as we understand them would seem to demand that Exchange/365, if indeed used currently, must be for the chop too.
I cannot speak on the delights of Outlook itself (in this much if nothing else in this life, I've been blessed) but I have had occasion to fake Exchange in the past, and for this I used the Horde webmail/groupware platform. It is anything but a drop-in replacement (LAMP stack and your choice of mail server component(s), advanced auth schemes and whatnot are left for you to sort out) but I found it quite capable in passing itself off as Exchange to mobile clients via EAS, including policy/provisioning features such as remote-wipe. I didn't use it, but sharing calendar appointments via email seemed to be supported at least via the webmail frontend. And if the web UI is reasonably up to snuff, I'm not convinced the absence of a dedicated desktop client need be a dealbreaker. (Thunderbird ... exists, but last I heard its calendaring addon was a work in progress.)
Unfortunately it has been taking its sweet time over a PHP8-compatible release, but it looks like the pace is picking up and that may arrive soonish.
Disclaimer: Thanks to my charmed life I may well lack critical insight in what people actually *do* in Outlook that's so special and unique besides bazzing appointments into each other's calendars or seamlessly responding yeah/nah to programmatic solicitations for same.
... then (AIUI) you'll need a Microsoft account in order to use it. So, no ta.
Bad enough I can't (seem to find a way to) use my fingerprint-reader without signing up. Dual-account strategy will have to continue to suffice.
They have done their best to make it all but mandatory. Wonder what the next gambit will be?
Just two days ago I decided to toy with cups-browsed on my Gentoo box (you'll be stunned to learn that it is not default-installed there!) because both my home and work printers now allegedly support "driverless printing"/"IPP Everywhere" which to anyone who's installed a printer on Linux was a rather tantalising promise, and browsed + Avahi seem to be the only endorsed way of achieving this.
In neither case did it work, if by "work" we mean "allow me to print a web page from Firefox on that printer".* So that was as far as that went.
I've always regarded Avahi/uPnP/DNSSD/Bonjour/mDNS/zeroconf (jeez, pick a name already) as asking for trouble to begin with, but will allow that it's what implementers do with it that you have to watch out for. I can't think of a much better example of doing something really stupid with it than accepting arbitrary, potentially root, code from any old Tom Dick or Kyocera that claims it's a printer.
I could see this being a useful way of frictionlessly adding a printer *if* used solely as an on-demand, one-shot "scan for printers" function when you actually know of a printer that you expect to find (and what it's probably called) on your network. Having it running permanently is bonkers. A server to handle the vanishingly-infrequent task of configuring another server?
It wouldn't surprise me if a lot of "user-friendly" desktop distros do enable this by default -- or at least pull it in with CUPS itself -- so I get that a fairly high level of concern is warranted, albeit with the caveats expressed by others.
[*Not that way it doesn't, but it is actually trivial to add these printers through CUPS's web UI if you know the printer's IP and the seemingly fairly universal format for ipp:// URIs.]
Seems the real issue was the "hundreds of times" part, which was just sloppy coding. The webapp could have been patched before the switch was thrown, so it'd stop trying to pull content when it wasn't logged-in. Apparently this didn't occur to anyone (who still worked there).
