Re: [DNG] librezilla: [WAS: Has anyone tried waterfox?]

[m712]

My account had 'nomail' set for a while so I can't reply to the original, so 
I'm replying over Enrico's message.

On 23.09.2017 10:51, Miroslav Rovis wrote:
>
>of google's intrusivity; they can put most any spyware in videos, and I'm
>looking for the knowhow how to safely deal with Youtube videos, a very hard to
>gain knowledge, very advanced... not nearly there, not even in my dreams there
>yet...
You can work over that by disabling Youtube JS and then adding a plugin to 
parse the Youtube JS and get the video link. youtube-dl does exactly this (they 
have a really tiny jsinterp.py file which can extract variables. It doesn't 
execute any code, and has no control flow). You can bundle the latest version 
of youtube-dl in an addon which rewrites the YouTube page to contain a simple 
native browser video and video information only, and then update it every time 
youtube-dl is updated. This would prevent users to comment, but if they really 
want to comment they'll need to turn on JS.
Or if you're lazy you can redirect youtube to HookTube.
--- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) --- :^) ---
https://nextchan.org - https://gitgud.io/m712/blazechan
I am awake between 7AM-12AM UTC, hit me up if something's wrong

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

Re: [DNG] Allwinner Olimex OLinuXino MICRO (A20) Devuan Jessie no Ethernet

[mdn]

It's being a while but I remember having trouble because the ethernet
MAC address is randomly generated at each start.

Le 12/10/2017 04:44, Nate Bargmann a écrit :
> I just received a Olimex OLinuXino MICRO (A20) board yesterday and have
> been playing with it.  It works just fine with the Olimex provided
> Debian Jessie.  As I would like a newer kernel to use BTRFS with a SATA
> drive, I found my way to our friendly Devuan images.  I imaged a
> different micro SD with the embedded Devuan image as instructed in
> https://files.devuan.org/devuan_jessie/embedded/README.txt and it boots
> and runs just fine.  The problem is that the ethernet port simply isn't
> passing traffic (it works just fine with the Olimex official image).
> 
> DHCP fails and even if I assign a static IPv4 address I cannot ping the
> MICRO nor can I ping from the MICRO with the Devuan image either a LAN
> IP address and DNS resolution fails.  I'm not sure if there is a module
> missing or not.  Looking through syslog provided no obvious clues other
> than the DHCP client logging that eth0's link was not ready.
> 
> If there is a better venue to ask about this, please let me know.
> 
> - Nate
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

-- 
Librement
BERNARD

FR: Veuillez s'il vous plaît utiliser GPG pour nos futures conversations:
https://emailselfdefense.fsf.org/fr/
Si cet email n'est pas signé, il ne vient pas de moi.

ENG: Please be kind enough to use GPG for our future conversations:
https://emailselfdefense.fsf.org/en/
If this email isn't PGP signed then it isn't mine.

-If you can't compile it dump it.



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Allwinner Olimex OLinuXino MICRO (A20) Devuan Jessie no Ethernet

[Nate Bargmann]

I just received a Olimex OLinuXino MICRO (A20) board yesterday and have
been playing with it.  It works just fine with the Olimex provided
Debian Jessie.  As I would like a newer kernel to use BTRFS with a SATA
drive, I found my way to our friendly Devuan images.  I imaged a
different micro SD with the embedded Devuan image as instructed in
https://files.devuan.org/devuan_jessie/embedded/README.txt and it boots
and runs just fine.  The problem is that the ethernet port simply isn't
passing traffic (it works just fine with the Olimex official image).

DHCP fails and even if I assign a static IPv4 address I cannot ping the
MICRO nor can I ping from the MICRO with the Devuan image either a LAN
IP address and DNS resolution fails.  I'm not sure if there is a module
missing or not.  Looking through syslog provided no obvious clues other
than the DHCP client logging that eth0's link was not ready.

If there is a better venue to ask about this, please let me know.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us


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

[DNG] Upgrade to ascii not possible?

[Yevgeny Kosarzhevsky]

Hello,

I've stuck on upgrading to ascii as there is no init-system-helpers
available.
Is there any solution?

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

Re: [DNG] librezilla: [WAS: Has anyone tried waterfox?]

[taii...@gmx.com]

On 10/11/2017 11:29 AM, Enrico Weigelt, metux IT consult wrote:


On 23.09.2017 10:51, Miroslav Rovis wrote:

Except with Udoo the *fake* open hardware. Based on Intel x86 
processor, as I

strongly suspect.



Maybe we should set up a public list of open vs. proprietary hardware,
a big hall of fame and hall of shame. Laud the good and blame the bad.
I recently stated the same on the coreboot mailing list, I think we 
should collaborate to create one.


Propriatary hardware isn't really an issue if it is sold as such, but so 
many companies sleaze out and sell it as "open hardware" ex: the RPI, 
purism, udoo, orwl, etc which sucks money from the actual libre hardware 
providers (of which there is at least one in every market segment)


Reposted:
In addition to the existing FSF RYF system I propose the creation of a 
"Freedom Inside" rating and certification system where vendors (now that 
there are more than a few) can have their products certified by a 
central body.


This would have:
Multiple levels of freedom with a clear central website with 
explanations of what each freedom level is (low, med, high, or something 
to that effect).

Standardized requirements for company marketing
Everything agreed upon on by various community experts "request for 
feedback"
Indicators of performance level and market segment on the intel inside 
style badge placed on every device (eg: the laymen could use an ARM 
laptop day to day, but has no idea how it compares to an x86 device - 
nor does he know that $2K is a actually a good deal for performance 
server hardware)
Ease of source-compilation requirement, so that the average power user 
can easily roll their own (ex: no getting unsigned 5 year old libs from 
a shady website)


I also propose a hardware-freedom-generic mailinglist be created for 
philosophy debates, "should I buy X?", newbie questions etc moreso now 
that TALOS 2 is in the picture the hardware freedom world is more than 
just coreboot so I think it would be a great idea.

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

Re: [DNG] Devuan, Firefox and Apulse

[dev]

On 10/11/2017 12:26 PM, Enrico Weigelt, metux IT consult wrote:
> On 26.09.2017 09:43, taii...@gmx.com wrote:
> 
>> They haven't put the users at #1 for a long time, why do you think
>> that firefox is still very vulnerable to browser fingerprinting? that
>> is by design.
> 
> Yes, and its getting worse: now they want to include cliqz - a spyware


What the actual hell, Mozilla!??

"About a year ago, Mozilla announced a strategic investment in Cliqz
GmbH,"..."Users who receive a version of Firefox with Cliqz will have
their browsing activity sent to Cliqz servers, including the URLs of
pages they visit."

https://blog.mozilla.org/press-uk/2017/10/06/testing-cliqz-in-firefox/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] librezilla: [WAS: Has anyone tried waterfox?]

[Enrico Weigelt, metux IT consult]

On 23.09.2017 10:51, Miroslav Rovis wrote:


Except with Udoo the *fake* open hardware. Based on Intel x86 processor, as I
strongly suspect.



Maybe we should set up a public list of open vs. proprietary hardware,
a big hall of fame and hall of shame. Laud the good and blame the bad.


And librezilla sounds interesting... (Upfront to say, I might only contribute
with testing once Alpha is out, very restricted developer skills here.)


We need testers. And we also need community organizers.


But setting it's home to maillist at google is repelling to me.


That was just a quick start - haven't had the time to set up an own
infrastructure yet. If you've got something better, you're highly
welcomed.


Well, then, if it doesn't involve web, pls. Enrico, make it plain clear to
people they don't have to subscribe to Schmoog groups to participate (because,
i.e. in Beagles groups you can read many figured out they needed to, else they
wouldn't be able to participate)... if/once your project takes off. In case
you, instead, can't, or have no time to, get it somewhere open and free from
privacy risk (would be much better!).


I'm currently lacking time to care about such infrastructure.

I've got a spare box @1+1, which still has to be set up (w/ devuan + 
containers, mta, ...), but haven't had the time to do it. If you'd like

to help, just let me know (feel free to call me: +49-151-27565287)


Gefährdeter Datenschutz: Firefox löscht lokale Datenbanken nicht


Data privacy in danger - firfox does not delete local databases.

In short: on "delete browsing data", the website's local databases
are not deleted - you'll have to do it manually, the hard way
(rm'ing the corresponding files within the profile).


Nach meinen Erfahrungen mit den Mozilla-Leuten sind das offenbar keine Bugs,
sondern Features.


According to my experience w/ the Mozilla folks, these are likely not
bugs, but features.


Für Datenschutz und Privatssphäre haben überhaupt kein Verständnis
(wundert auch nicht - saßen ja lang genug mit Google zusammen im Haus).


No understanding for data protection whatsoever (not surprising, they've
been sitting together w/ Google in the same building long enough)


But Enrico talks about how they censor people who even come with simple
questions about things (I could prove I was censored myself by Mozilla!), and
he talks more, and ends that email with saying how he has already started
*Librezilla*.


Correct. My fork is yet in an early stage - yet based on esr52, which of
course is just an intermediate approach (I just didn't want to cope w/
the  rust hell yet)


Brought that here, because for a while, Germany was looked at as the future
leader in the return of the respect for privacy, by people like Julian Assange
and Edward Snowden... Alas, hasn't been materializing yet...


The people: yet.

The regime: clearly not. This occupation regime has a long history of
suppressing free speech (people get into jail when publicly questioning
the official hi-story of the 30th/40th, psychiatrized when uncovering
massiv fraud and corruption, etc).

They even recently passed a legislation to spy on basicly everbody w/o
any evidence (network enforcement act), with a small minority, without
a quorate parlament - just like Hitler did w/ his enablement act in
1933.

Germany indeed is ruled by a fascist regime, but resistance is growing.
More and more people are working on rolling back the corporate
occupation and reactivating the original home states. We don't have
anything like the constitutional sherrifs yet, but (especially triggered
by the Merkel's huge crimes, eg. opening the borders for invasion) more
and more police and military people are silently switching sides and
prepare for civil war.


But... unill, and if, Librezilla reaches Alpha, I think Palemoon is an 
acceptable
option. My install is from Steve Pusser's repo at SuSE, but I recompiled the
sources without dbus
(
all my Devuan systems are sans-dbus at this time, something unfeasible with
almost any GNU/Linux distro other than Devuan and Gentoo --but currently no
Gentoo here--;


Yes, PM seems a good start. We should try to get them onboard and create
a bigger community.


---
of google's intrusivity; they can put most any spyware in videos, and I'm
looking for the knowhow how to safely deal with Youtube videos, a very hard to
gain knowledge, very advanced... not nearly there, not even in my dreams there
yet...


How are they doing that ? EME ?


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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[d_pridge]

Can you rename the files, instead, by adding _removed_by_rc.local.


Sent from my MetroPCS 4G LTE Android Device
 Original message From: Didier Kryn  Date: 
10/11/17  2:03 AM  (GMT-06:00) To: dng@lists.dyne.org Subject: Re: [DNG] 
systemd-udevd: renamed network interface eth0 to eth1 
Le 11/10/2017 à 08:10, Dr. Nikolaus Klepp a écrit :
> Am Mittwoch, 11. Oktober 2017 schrieb John Morris:
>> On Tue, 2017-10-10 at 01:49 +0200, Alessandro Selli wrote:
>>
>>>    By the manual, the correct solution in configuring Grub as to pass the
>>> kernel these parameters:
>>>
>>> biosdevname=0 net.ifnames=0
>> Those fix similar problems but not exactly the same ones.  The udev
>> persistent rules get you when you move an image from one machine to
>> another or swap out failed hardware and suddenly you have no network
>> because eth0 suddenly became eth1.  And as I noted, not only network
>> device names but CD drives as well are impacted.  The fixes you suggest
>> solve the equally annoying problem of eth0 or wlan0 unexpectedly turning
>> into a string of gibberish after an upgrade.
>>
>> They are turning everything into a UUID or similar string of untypable
>> gibberish.  It is almost like they don't want you to use the command
>> line directly anymore.  Nah, that couldn't be it, right?
>>
> My rc.local contains this line:
>
> rm /etc/udevd/rules/*persist*

 With this, Udev starts from scratch at every boot :-)

 Looks like a very nice approach, but it's too hidden: if you 
inherit a machine which is doing that, it can take you pretty long 
before you find out who the hell is deleting the udev rules. Maybe 
rewrite the files with only a comment like

# This file has been wiped out by /etc/rc.local because I don't want 
udev to rename my devices.

 Didier


___
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] systemd-udevd: renamed network interface eth0 to eth1

[Didier Kryn]

Le 11/10/2017 à 09:32, Dr. Nikolaus Klepp a écrit :

Am Mittwoch, 11. Oktober 2017 schrieb Didier Kryn:

Le 11/10/2017 à 08:10, Dr. Nikolaus Klepp a écrit :

Am Mittwoch, 11. Oktober 2017 schrieb John Morris:

On Tue, 2017-10-10 at 01:49 +0200, Alessandro Selli wrote:


By the manual, the correct solution in configuring Grub as to pass the
kernel these parameters:

biosdevname=0 net.ifnames=0

Those fix similar problems but not exactly the same ones.  The udev
persistent rules get you when you move an image from one machine to
another or swap out failed hardware and suddenly you have no network
because eth0 suddenly became eth1.  And as I noted, not only network
device names but CD drives as well are impacted.  The fixes you suggest
solve the equally annoying problem of eth0 or wlan0 unexpectedly turning
into a string of gibberish after an upgrade.

They are turning everything into a UUID or similar string of untypable
gibberish.  It is almost like they don't want you to use the command
line directly anymore.  Nah, that couldn't be it, right?


My rc.local contains this line:

rm /etc/udevd/rules/*persist*

  With this, Udev starts from scratch at every boot :-)

  Looks like a very nice approach, but it's too hidden: if you
inherit a machine which is doing that, it can take you pretty long
before you find out who the hell is deleting the udev rules. Maybe
rewrite the files with only a comment like

# This file has been wiped out by /etc/rc.local because I don't want
udev to rename my devices.

  Didier

Comments are overrated. Remember the holy church of cleancode? Levels out the 
differences between managment and coders: With cleancode not only managers dont 
understand code, coders don't  ether!

Nik


Well, this isn't code, its only management, but there might be a 
holy church of cleanmanagement as well. I would say it's a matter of 
taste to let comments or not when you hack your system :-)


Didier

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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[Alessandro Selli]

Il giorno Tue, 10 Oct 2017 22:25:23 -0500
John Morris  ha scritto:

> On Tue, 2017-10-10 at 01:49 +0200, Alessandro Selli wrote:
>
>>   By the manual, the correct solution in configuring Grub as to pass the
>> kernel these parameters:
>> 
>> biosdevname=0 net.ifnames=0
>
> Those fix similar problems but not exactly the same ones.

  Agree.  udev rules confer a given piece of hardware a given name.  Those
kernel parameters instruct the kernel not to let network interfaces be
renamed by userland.

>  The udev
> persistent rules get you when you move an image from one machine to
> another or swap out failed hardware and suddenly you have no network
> because eth0 suddenly became eth1.

  Well, if you had a /etc/udev/rules.d/70-persistent-net.rules file that
renamed a network interface identified by its MAC address eth0 and you
swapped that card for a new one, then the new one is going to get a
different name because eth0 was already taken.  If you used those kernel
parameters instead it would be named eth0.  Which is what you'd expect if it
was the only ethernet card on board.

>  And as I noted, not only network
> device names but CD drives as well are impacted.

  I think for CDs and DVDs the biosdevname=0 parameter suffices.  It used to
be all it was needed to prevent networking gear from being renamed, but at
some point they added the net.ifnames=0 parameter that is specific to
ethernet cards.

>  The fixes you suggest
> solve the equally annoying problem of eth0 or wlan0 unexpectedly turning
> into a string of gibberish after an upgrade.

  Pretty annoying, agree.  That's the reason I enquiried about the possible
ways to prevent the renaming from happening.

> They are turning everything into a UUID or similar string of untypable
> gibberish.  It is almost like they don't want you to use the command
> line directly anymore.  Nah, that couldn't be it, right?

  I don't think that's the reason, many critical Linux systems are run and
managed without a GUI, just think of supercomputers, clusters, IoT and
embedded devices. Carrying around a complex device name is not such an issue,
you just export an ETH0 variable with it's name and use $ETH0 in place of
eth0 on the commands you type.  I still do prefer typing just eth0, I'm such
a lazy sysadmin!  :-)


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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[Dr. Nikolaus Klepp]

Am Mittwoch, 11. Oktober 2017 schrieb John Morris:
> On Tue, 2017-10-10 at 01:49 +0200, Alessandro Selli wrote:
> 
> >   By the manual, the correct solution in configuring Grub as to pass the
> > kernel these parameters:
> > 
> > biosdevname=0 net.ifnames=0
> 
> Those fix similar problems but not exactly the same ones.  The udev
> persistent rules get you when you move an image from one machine to
> another or swap out failed hardware and suddenly you have no network
> because eth0 suddenly became eth1.  And as I noted, not only network
> device names but CD drives as well are impacted.  The fixes you suggest
> solve the equally annoying problem of eth0 or wlan0 unexpectedly turning
> into a string of gibberish after an upgrade.
> 
> They are turning everything into a UUID or similar string of untypable
> gibberish.  It is almost like they don't want you to use the command
> line directly anymore.  Nah, that couldn't be it, right?
> 

My rc.local contains this line:

rm /etc/udevd/rules/*persist*

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng