Re: [DNG] vdev - scanner

[Ralph Ronnquist]

Dave Turner wrote on 02/09/16 20:12:

On 02/09/16 01:38, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev
tree dealing with, say, scanners or, say, mode switching USB devices.
Since those are major chunks in udev rules, I'm just confused. Have I
misunderstood?

I find "scanner" mentioned in the hwdb, but there is no formal
classification of those other than identifying as usb (or pci);
nothing classifying them as scanners (unless you'd regard the model
label as such). I wish someone could explain things for me...

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


I loathe the 'feature' of udev that forces you to create or modify
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted
Android Device get through udev security. And now it seems that vdev is
about to force the same thing. I know it isn't easy to completely
re-think how things should be done, do OSX and the BSDs have a different
and better way of doing this sort of thing?

I want to ask you why a database of $V/$P/$N mappings is needed. It is
my laptop and my cheap Android tablet and I want to plug it into the USB
socket and have them play nicely together. God knows what I would have
done if I was just a normal ordinary person. I would have concluded that
linux was shit and gone back to my Mac or Windoze.

dmesg knew all about my android tablet when I plugged it in, why can't
vdev pick it up from there?

this is what I had to add into 51-android having had a look at dmesg first.

#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"


I suppose the issue is to make sure that the right user have the right 
access to the right devices when she wants to use the computer, whilst 
making sure that the wrong user doesn't have the wrong access regardless 
of what he wants to do.


Traditionally on Linux, the means to achieve this would be to use file 
permissions. Then more recently, the notion of access control lists was 
invented to offer a more dynamic access control. And then even more 
recently "people" have decided that this is an insanely hard problem, 
which requires an insane solution.


Given the scope of possible use cases, perhaps the permission handling 
should be taken elsewhere, and make the hotplug handler only deal with 
ensuring the device is functional and available to the permission 
handling sub system. Maybe even the latter could be PAM (although I 
don't know if PAM can make device access be allowed rather than just 
judging whether or not it is allowed).


Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OT: On the subject of learning how to use what you have

[Simon Hobson]

It's come up a few times that a lot of problems "with" ${package} aren't 
actually problems with the package, but people who didn't bother to learn how 
to use it properly.
Today's XKCD seems to fit in with that quite nicely - especially the rollover 
popup :-)

http://xkcd.com/1728/

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - android

[Ron]

On Fri, 2 Sep 2016 09:59:29 -0400
Hendrik Boom  wrote:

> Have things changed?

ISTR that they changed between Android 4 and Android 5; my 4 tablet mounted 
directly, while for my daughter's 5 phone I had to install some packages.
 
Cheers,
 
Ron.
-- 
 When men are pure, laws are useless;
when men are corrupt, laws are broken.
  -- Benjamin Disraeli

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - android

[Hendrik Boom]

On Fri, Sep 02, 2016 at 11:12:00AM +0100, Dave Turner wrote:
> 
> dmesg knew all about my android tablet when I plugged it in, why can't vdev
> pick it up from there?
> 
> this is what I had to add into 51-android having had a look at dmesg first.
> 
> #my cheap Android tablet
> ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"

The real question is whether there's another way to identify what a kind of
device it is.

Androids see to be mtp devices if you want to mount them as a file 
system.  Linux has some obscure command to mount such things.  I forget 
what.
 
They aren't USB storage devices.  At least, mine wasn't.

If you don't want to mount it, you use adb to access it.

At least, mtp and adb are the official ways to access them.
Have things changed?

-- hendrik

> 
> DaveT
> 
> (idiot boy managed to hit Reply instead of Reply List, icedove isn't as good
> as it thinks it is...)
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vagrant and devuan guest

[Fred DC]

On 02/09/2016 10:04, Attila Soki wrote:
> ...
> Of course a devuan plugin would make all this unnecessary.
> But before i can file a bug, or maybe create a devuan plugin, i must
> know which is the preferred way to identify devuan.
> grepping /etc/issues
> or
> grepping /etc/os-release
> or
> ?

This is not the answer to your question but in Devuan-Ascii:

xxx:~$ cat /etc/issue
Devuan GNU/Linux ascii/ceres \n \l

xxx:~$ cat /etc/os-release
PRETTY_NAME="Devuan GNU/Linux ascii/ceres"
NAME="Devuan GNU/Linux"
ID=devuan
HOME_URL="http://www.devuan.org/;
SUPPORT_URL="http://www.devuan.org/support/;
BUG_REPORT_URL="https://bugs.devuan.org/;

Maybe in a new install of Devuan-Jessie it is already sorted out.

Fred



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - scanner

[Arnt Gulbrandsen]

The key here is that linux doesn't assume one user. You get to answer, from 
first principles, whether a particular USB device belongs to user x or to 
root, etc. The mac has a stronger assumption that your mac belongs to you 
(which is why the default hostname is "Dave Turner's Mac", etc) and what 
you plug in does too.


I like the way KDE handles/handled USB sticks: The version of KDE I'm 
running asks me about USB sticks the first time and remembers each stick 
forever, so if I plug in my keyring stick now the linux box will automount 
it. That would be a fine way to handle phones too.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev - scanner

[Dave Turner]

On 02/09/16 01:38, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 01/09/16 08:51:


My worry is that the OS_TYPE=255/255/255 condition is not distinct
enough to make the action apply exactly and only for scanners. Comparing
with udev rules, you'll find there are more than a few rules for USB
devices, and almost all of them make their classification based on the
vendor/product pair (rather than the capability declarations).
...


I'm a little bit at a loss here, as I can't find anything in the vdev 
tree dealing with, say, scanners or, say, mode switching USB devices. 
Since those are major chunks in udev rules, I'm just confused. Have I 
misunderstood?


I find "scanner" mentioned in the hwdb, but there is no formal 
classification of those other than identifying as usb (or pci); 
nothing classifying them as scanners (unless you'd regard the model 
label as such). I wish someone could explain things for me...


Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


I loathe the 'feature' of udev that forces you to create or modify 
/etc/udev/rules.d/51-android to let your cheap'n'cheerful unlisted 
Android Device get through udev security. And now it seems that vdev is 
about to force the same thing. I know it isn't easy to completely 
re-think how things should be done, do OSX and the BSDs have a different 
and better way of doing this sort of thing?


I want to ask you why a database of $V/$P/$N mappings is needed. It is 
my laptop and my cheap Android tablet and I want to plug it into the USB 
socket and have them play nicely together. God knows what I would have 
done if I was just a normal ordinary person. I would have concluded that 
linux was shit and gone back to my Mac or Windoze.


dmesg knew all about my android tablet when I plugged it in, why can't 
vdev pick it up from there?


this is what I had to add into 51-android having had a look at dmesg first.

#my cheap Android tablet
ATTR{idVendor}=="1f3a", ENV{adb_user}="yes"

DaveT

(idiot boy managed to hit Reply instead of Reply List, icedove isn't as 
good as it thinks it is...)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tor and systemd?

[Arnt Karlsen]

On Fri, 2 Sep 2016 09:12:49 +0800, Brad wrote in message 
:

> On 02/09/16 00:20, Arnt Karlsen wrote:
> >
> > ..we honk that nice big red "No-Shit???" horn now? ;o)
> > https://www.torproject.org/docs/faq.html.en#Backdoor
> >
> > ..to the Tor people: systemd made its way into Debian on banana
> > republic politics, not on tech merit.  Devuan tries to become a
> > non-systemd fork, and not a death trap to the next Ed Snowdon.
> >
> > ..since I didn't subscribe to your mail lists, I'm totally fine
> > with you guys rejecting my post there, just kick libsystemd0 off
> > any Tor packages until Edward Snowdon tells me in person here in
> > Norway, he is the man behind SystemD.
> 
> 
> Please tell me you didn't send that to the tor list.

..I did not register there, and they rejected my post "attempts" 
there, precisely the way I wanted them to, the idea is make them 
aware in case they weren't.

> For the love of all that is holy stop trying to make the Devuan
> project look like tinfoil-hat doomsday preppers.

..with Trump and Hillary running for President? ;oD

..we have Putin "next door" and our _Blond_Regime_ is _still_ 
cutting Norw. defense down by US$2Billion, budget year 2017.
We have _no_ anti-aircraft nor anti-missile defense other 
than human shields like in Aleppo, Syria since 1994, and 
the _only_ way I see Hillary escape jail time, is WWIII.

> If you don't like tor pulling in systemd, then *fix* it. Don't go 
> hysterically screaming about the sky falling and dropping names like 
> "Edward Snowd*e*n" without good reason.

..has Ed, or Tor people had time to learn about how systemd 
_can_ subvert Tor? 
I haven't, post-Groklaw litigation.

> If you are going to drop
> names, spell them correctly. Not doing so makes you look even more of
> a ranting lunatic.

..damn, apologies.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vagrant and devuan guest

[Attila Soki]

> Am 02.09.2016 um 03:01 schrieb Daniel Reurich :
> 
> Hi Attila,
> 
> On 01/09/16 23:36, Attila Soki wrote:
>> 
>> As far as i understand, vagrant failed to determine which os the guest is 
>> running.
> 
> 
>> but, i dont know if there is any interest to solve this problem and then, 
>> which one is the preferred way..
>> 

> 
> Please File a bug against vagrant.  It should handle the case where the
> distrobution vendor is not known.  Also Devuan has been around long
> enough that it should have support added to handle Devuan properly
> without retaining a reference to 'Debian' in /etc/issue.


To answer my own question: rtfm.
There is no need to modify anything in devuan in order to make it boot with 
vagrant. Vagrant has already a configuration option where the guest os can be 
set when the auto-detection fails.

https://devuan.org/os/documentation/install-on-a-virtual-machine
config.vm.guest = :debian

Of course a devuan plugin would make all this unnecessary.
But before i can file a bug, or maybe create a devuan plugin, i must know which 
is the preferred way to identify devuan.
grepping /etc/issues
or
grepping /etc/os-release
or
?

Thanks,
Attila
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng