@kyle @purism I would rather disagree here. I as a corp CISO just apply zero-trust model and ring-fence corp data at all perimeters, starting from user-end-point and ending internet/service perimeter. I, as a parent, want to protect my kid from dangers of the digital wilds. Now this is for convenience (I'm not a watch dog, i teach my kids but I know they are not ready yet. Kids develop themselves differently).
@purism @kyle and then there's UEM/EMM/MDM - but you still have a choice - if you don't want the corp to control your device (with your consent - which is important) just don't access corp resources from your device. simple.
My point is - corp control of corp owned endpoints has nothing to do with the mess google and apple are throwing upon us. they may use similar tech, but that's about it.
@purism
"The most common justification for these policies is convenience."
stopped reading.
@kyle with all due respect I know you can do better than that. Parental control is about controlling *your* device from your kids (when they buy their own you lose that control). Corp policies are about controlling *corp* devices. When you go all byod you apply NAC and security posture control as you cannot change device you don't *own*.
@kyle something is wrong with you :) I'm wearing my pebble for about the same time but I only check them when a) i need to check time b) it vibrates so i _may want_ (not *must*) to check what's there c) I want to use some of the apps (calendar, compass, weather) d) whether bluetooth is connected (eg do I have a phone with me or forgot it somewhere)
@fnord @kyle It's about ToS. In corp network you have your standards and even the fact of being non-compliant with standards is ToS violation. ISP may cut your subscriber's line if you violate ToS (eg detected malicious activity/abuse) but not proactively because they suspect you may do it due to using unpatched devices.
@dos no, just debian is not up to being rolling, try arch and stay calm while still rolling. any time I try to use deb or rpm based system I'm becoming pissed with the [way] upgrades [are done]. and switch to either gentoo or arch.
@agx @x51@cybre.space I did, but in here [1] it's just a static boolean property, not sure what is supposed to track it.
1 - https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtkapplication.c#L1206
@agx @x51@cybre.space The reason being - system-activeness will likely be used by system services (non-toolkit apps) and top-of-the-stack while is a shell concept may still be wrapped into toolkit.
@agx @x51@cybre.space I would expect it rather opposite :) the screensaver (system-active) to be on a well-known dbus path and top-of-the-stack (app-active) to be toolkit-specific.
@agx @x51@cybre.space And this is in addition to system-inactive mode (which is when display is locked or off - neither application is active and even services may try to suspend activity to the bare minimum only to poll the states and keep notifications flying
@agx @x51@cybre.space I define it as the one which does not have display focus (user interaction), the one which executes in the background. On sailfish it is used to switch from normal/interactive to powersave/inactive mode. It is then up to developer how to make use of that inactive mode to extend battery life (considering user is not interacting with the app)
@agx @x51@cybre.space Are there concepts of active/inactive applications? if yes - how to switch ti "inactive" state without swithing to another app (eg switch to desktop)?
@KekunPlazas I know this mood. The fact it went into commit means the time wasn't wasted :)
@chrichri Yup I've opened a case with them, didn't get any response tho yet :) Either way I have a long xmas break and some tools to learn schematics and come up with the plan on how to debug and confirm whether it's me or the board.
@chrichri @martijnbraam and putting back original board makes it (touchscreen) working again. So it was a good experiment, almost flawless :)
Joined Nov 2019
