Add a cli tool to ease blacklisting

[humdinger]

Until there's a GUI to deal with blacklisting, managing the states that are saved in /system/packages/administration, offer backup/restore specific states maybe even integrate a sort of session management so the running apps etc. are saved when Haiku shuts down...

How about a CLI command "blacklist"? It would save finding and dealing with the driver_settings-formatted /system/settings/packages file. The blacklist command should work transparently wrt system/home hierarchy, as it can detect where to add/remove things from the path of the input.

Possible parameters:

• blacklist list to output the currently blacklisted items, e.g.:

  $> blacklist list
  1: /system/add-ons/kernel/drivers/bin/intel_extreme
  2: /system/add-ons/kernel/busses/usb/xhci
  

• blacklist drop|remove [module] [module] ... to remove one or more entries, e.g. to remove the 1st entry:

  $> blacklist drop 1
  

  or

  $> blacklist drop /system/add-ons/kernel/drivers/bin/intel_extreme
  

• blacklist add [module] [module] ... to add one or more 'modules' (add-ons, apps, whatever), e.g.:

  $> blacklist add /system/add-ons/kernel/drivers/bin/intel_extreme
  

[dcatt]

Since blacklist list sounds redundant, how about blacklist items OR simply blacklist, which will default to providing the list of items.

[humdinger]

"list" (or variations) is used with various Haiku cli apps, like desklink, diskimag, pkgman, screenmode, setarch... But defaulting to "list" with no parameters sound fine. But this is bike shedding that can be done when the rest is coded. :)

[dcatt]

I have to agree with you... convention is king. Ignore my 2 cents above :-)

[humdinger]

That said, it'd be nice if all the apps were more tolerant and accept "list" as well as "--list", for example. Many are accustomed to have single letter parameters as "-l" and word parameters as "--list". The choice to use "list" without the "--" has always struck me as odd. We could at least accept all variations where possible.

[pulkomandy]

This depends on where the people came from. The -l/--list way is from UNIX, while the Amiga tended to use a different syntax (for example "COPY FROM: drivea TO: driveb"). BeOS inherited some things from the Amiga way of doing things, and some from UNIX, and as a result the commands are a little mix and matched.

Back on-topic: I don't know if this is useful. I would say editing a text file is easier than using the command line. Maybe you are becoming too much of a power-user :)

A GUI app would definitely be nice. Maybe we should include that in the "devices" preferences, and also make it detect temporary blacklists and offer to make them permanent. So once you've found a setting that works from the bootloader menu, there is no need to redo it all inside the app. Adding a GSoC idea for this.

[humdinger]

Replying to PulkoMandy:

I would say editing a text file is easier than using the command line.

I still think it's easier (just like 'desklink' is nicer to use than if there were some driver_settings formatted text file). Consider also, the 'packages' file doesn't even exist by default, but has to be created in the right location from scratch. Don't get me wrong, compared to a nice GUI app, 'balcklist' would still suck; just a little less than without it.

A GUI app would definitely be nice. Maybe we should include that in the "devices" preferences, and also make it detect temporary blacklists and offer to make them permanent. So once you've found a setting that works from the bootloader menu, there is no need to redo it all inside the app. Adding a GSoC idea for this.

I don't think that fits too well. Blacklisting is not just for devices and drivers, but for any application, lib or add-on that's in the system (or home). I think eventually we need something more encompassing, as I hinted at in the first paragraph of the ticket.

[pulkomandy]

Blacklisting for apps? What is the use case for that?

I see the whole blacklisting as a hack overall. We should instead split the Haiku package in smaller chunks, so that each driver is in a separate package and it is possible to install and uninstall them separately. This is the right way to manage these things, I think.

[humdinger]

Replying to PulkoMandy:

Blacklisting for apps? What is the use case for that?

Maybe a system crashing bug in the app, which get auto-started by the launch daemon. Or someone wants to try their custom built Tracker. I dunno, people find all kinds of uses, and our blacklisting allows it.

I see the whole blacklisting as a hack overall. We should instead split the Haiku package in smaller chunks, so that each driver is in a separate package and it is possible to install and uninstall them separately. This is the right way to manage these things, I think.

Maybe. But then the installing isn't as fast anymore. Was pretty cool to see the GCI videos creating a VM, configuring and installing and rebooting Haiku in under 4 minutes. :)

[humdinger]

#18772 is a better suggestion. Using Tracker's add-on feature is easy, intuitive, and in line with the Haiku Way(tm) of not having to edit text files for configuration if possible.

[pulkomandy]

I'm not so convinced about that. While at first glances the Tracker add-on seems a nice idea, it raises a lot of questions on its own (I have commented there about it). I think a CLI app is going to be a lot easier than that.

[humdinger]

Fair enough, let's re-open this one then...