GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Saturday, 26-Apr-2025 06:42:38 JST David Chisnall (*Now with 50% more sarcasm!*) David Chisnall (*Now with 50% more sarcasm!*)

    I know people like to make fun of niche operating systems, but for the five years I was at Microsoft I used Windows (10 then 11) as my daily driver. It’s much less stable than a professional OS, but it does kind-of work. I wouldn’t say it’s ready for the desktop. The UI is inconsistent and changes randomly between releases, a load of common software is basically useable only in a VM, it lags and freezes periodically (unlike an OS designed for interactive use, random drivers run a load of things directly in interrupt handlers, so you get latency spikes that you wouldn’t see in a more mainstream desktop OS) and the update process can hose the system, so it’s mostly of interest to people who like tinkering with their machines than people who actually want to get work done. Oh and a load of random bits of the OS have ads, but that’s what you get from a free ad-supported system instead of one developed by an active open-source community.

    I don’t think I’d recommend anyone use it as their daily driver or in a work setting, but it’s not totally unusable. It’s not at the level of maturity than you’d expect from, say, Linux or FreeBSD, especially not for client workloads. If you do have to use it, I recommend that you install FreeBSD in a Hyper-V VM for real work. That’s what I did and it works quite well.

    In conversation about 2 months ago from infosec.exchange permalink
    • Haelwenn /элвэн/ :triskell:, Doughnut Lollipop 【記録係】:blobfoxgooglymlem: and prettygood like this.
    • Rich Felker repeated this.
    • Embed this notice
      amy (amy@kokoro.garden)'s status on Monday, 28-Apr-2025 19:53:38 JST amy amy
      in reply to

      @david_chisnall Drivers doing too much in interrupt handlers answers a lot of questions I had about windows..

      In conversation about a month ago permalink
      Rich Felker repeated this.
    • Embed this notice
      David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Monday, 28-Apr-2025 19:53:43 JST David Chisnall (*Now with 50% more sarcasm!*) David Chisnall (*Now with 50% more sarcasm!*)
      in reply to
      • amy

      @amy I learned that accidentally. I was discussing how to adopt a security feature in NT and someone on that team casually mentioned third-party drivers (including antivirus) running things in interrupt handlers. The more I learned, the more horrified I was. On FreeBSD and XNU, interrupt handlers do one thing: wake a thread (or some work-queue equivalent). The thread is then preemptive. A small number of things run with interrupts disabled but it’s very rare in drivers or subsystems outside the very core parts of the OS. In Windows, the driver model seems to encourage people to just do the real work in interrupt handlers. So your USB camera is stalling a core (and whatever thread is currently trying to run there) for ms at a time, and so are a load of other kernel things.

      Even FreeRTOS discourages this kind of thing, and it’s designed for a use case where it isn’t a terrible idea.

      In CHERIoT RTOS we formalise it and bind interrupts to futexes, so the only thing that happens in an interrupt handler is that one or more futexes get woken and then we may make a scheduling decision if any of the woken threads are higher priority than the one that woke (on our chips, we have designed the interrupt controller so that it can avoid raising an interrupt if it wouldn’t result in a scheduling decision).

      In conversation about a month ago permalink

      Attachments


    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Monday, 28-Apr-2025 20:00:29 JST Rich Felker Rich Felker
      in reply to
      • amy

      @david_chisnall @amy A proper OS shouldn't even have a way to do things from interrupt handlers, or a concept of interrupt handlers (plural). There should be one interrupt handler that maps the interrupt to a list of hardware devices associated with it and fires a wake event for any drivers attached to each of them, then immediately returns, with no way to override that.

      In conversation about a month ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.