Re: [arch-general] unreadable characters login screen after install

[Nick Name]

 On Sat, 26 Nov 2016 17:08:06 +0100 Ralf Mardorf 
wrote  
 > Which login screen? 
 >  
 > A display manager's greeter? If so, xorg.conf or display manager settings 
 > might solve the issue. 

Oops, I was confusing keyboard with fonts. Not xorg.conf, but much likely the 
display manager configuration provides to chose a font.

 >  
 > Or tty?
 > 

Re: [arch-general] unreadable characters login screen after install

[Ralf Mardorf]

Which login screen?

A display manager's greeter? If so, xorg.conf or display manager settings might 
solve the issue.

Or tty?

[arch-general] unreadable characters login screen after install

[niya levi via arch-general]

hi everyone
after an install following the wiki installation guide and rebooting
the login  screen shows unreadable characters,
the char displays as rectangular and square blocks,
locale.conf is set to LANG=en_GB.UTF-8
vconsole.conf is set to KEYMAP=uk
i also tried adding a FONT= line to vconsole.conf while chrooted the but
no joy after rebooting,
the installation screen was fine.
any ideas ?

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries 

> To my knowledge, makechrootpkg uses systemd-nspawn, which means it is
> already using a container. Reproducible builds will need quite a bit more
> work than simply using containers though.

I only meant reproducible environment but failed to make that clear.
This is why I was mentioning a clean env with only what's required
to build per recipe and not mistakingly building with stuff that's
in /usr.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Bennett Piater  wrote:
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build environments
>> for building arch packages. It would also allow installing makedeps only in
>> the container/chroot or make cross-compilation easier to manage.
>>
>> Are there plans to support this in makepkg? I believe xbps has this.
>
> Out of curiosity, what's wrong with makechrootpkg?

Thanks I wasn't aware of it.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries  wrote:
>
>
> On 26 November 2016 at 15:08, Carsten Mattner via arch-general
>  wrote:
>>
>>
>> Another very useful case would be using containers as a chroot replacement
>> for having clean (only what's in the recipe), reproducable build
>> environments
>> for building arch packages. It would also allow installing makedeps only
>> in
>> the container/chroot or make cross-compilation easier to manage.
>>
>> Are there plans to support this in makepkg? I believe xbps has this.
>
>
> To my knowledge, makechrootpkg uses systemd-nspawn, which means it is
> already using a container. Reproducible builds will need quite a bit more
> work than simply using containers though.
>
> And since this whole thread is widely off topic already, there is a totally
> different approach to isolating untrusted apps: cloudabi [1]. Instead of
> making isolated traditional posix environments to run untrusted
> applications, cloudabi makes it impossible to access global resources such
> as the filesystem and network by providing only a subset of system calls.
> For example, there is no `open()` syscall, but there is `open_at()`.
> Resources can be given to the process by leaving open file descriptors when
> it is exec'd, or by sending file descriptors to it over a unix socket.
>
> The biggest drawback is of course that existing software can't simply run
> under cloudabi because there are syscalls and libc functions missing. Also,
> controlling access to network resources is troublesome, but I like the
> general idea: instead of adding complexity of multiple isolated
> environments, cloudabi removes complexity by stripping system calls that can
> access global resources. There is a working patchset for the Linux kernel
> already, though not upstreamed yet. See [1] if you're interested.
>
> [1] https://nuxi.nl/

I know CloudABI from FreeBSD, where it's integrated like Capsicum
and netmap have been for a long time. It's unfortunate Linux suffers
from NIH in this context.

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Maarten de Vries via arch-general]

On 26 November 2016 at 15:08, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:

>
> Another very useful case would be using containers as a chroot replacement
> for having clean (only what's in the recipe), reproducable build
> environments
> for building arch packages. It would also allow installing makedeps only in
> the container/chroot or make cross-compilation easier to manage.
>
> Are there plans to support this in makepkg? I believe xbps has this.
>

​To my knowledge​, makechrootpkg uses systemd-nspawn, which means it is
already using a container. Reproducible builds will need quite a bit more
work than simply using containers though.

And since this whole thread is widely off topic already, there is a totally
different approach to isolating untrusted apps: cloudabi [1]. Instead of
making isolated traditional posix environments to run untrusted
applications, cloudabi makes it impossible to access global resources such
as the filesystem and network by providing only a subset of system calls.
For example, there is no `open()` syscall, but there is `open_at()`.
Resources can be given to the process by leaving open file descriptors when
it is exec'd, or by sending file descriptors to it over a unix socket.

The biggest drawback is of course that existing software can't simply run
under cloudabi because there are syscalls and libc functions missing. Also,
controlling access to network resources is troublesome, but I like the
general idea: instead of adding complexity of multiple isolated
environments, cloudabi removes complexity by stripping system calls that
can access global resources. There is a working patchset for the Linux
kernel already, though not upstreamed yet. See [1] if you're interested.

​[1] https://nuxi.nl/​

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Bennett Piater]

> Another very useful case would be using containers as a chroot replacement
> for having clean (only what's in the recipe), reproducable build environments
> for building arch packages. It would also allow installing makedeps only in
> the container/chroot or make cross-compilation easier to manage.
> 
> Are there plans to support this in makepkg? I believe xbps has this.

Out of curiosity, what's wrong with makechrootpkg?

-- 
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Carsten Mattner via arch-general]

On Fri, Nov 25, 2016 at 7:01 PM, pelzflorian (Florian Pelz)
 wrote:
> Containers are an attempt to solve multiple issues. One is being a
> replacement for bundles. When people sell and distribute a proprietary
> app/game, they presumably want it to run on as many systems as possible
> with as little effort as possible. Having to rely on volunteer
> maintainers is not good, neither is having to maintain a lot themselves.
> Software bundles with all libraries included are the traditional
> solution to this on all operating systems. Flatpak seems like an even
> easier solution.
>
> The real issue in this discussion is security. Traditional GNU/Linux is
> too monolithic. Having more separation between an application and lower
> system layers adds security just like not using root for running a Web
> server and using separate user accounts for e.g. a Web server and an
> XMPP server does. Well-behaved software uses the self sandboxing you are
> talking about: dropping capabilities, revoking privileges. Two issues
> remain:
>
> Presumably most software (online games in particular) do not properly
> self-sandbox and are not secured very well. It’s safest not to install
> such software on your work PC but you may still wish to somewhat protect
> your gaming PC. Despite not knowing the software that well, we can try
> to constrain its privileges via containers/bubblewrap/firejail.
>
> What’s still missing however is proper filesystem isolation. Not every
> program needs to have access to any file in my home directory. More
> separation here is good for security. I don’t want to create a new user
> account for each app. I do want to use something like the new xdg
> desktop portals. I also want to hide what other software I have
> installed. I planned to do something with many small Arch Linux
> filesystems with inheritance through hardlinks, but maybe embracing Guix
> as an additional per-user package manager is a better approach?
>
> The same missing separation may be a reason to use Mach/Hurd over Linux.
> Of course that is still in its infancy.

I'm no fan of the container (docker) craze right now, but I also agree on
the benefits listed above. Further, some applications or suites like KDE
or GNOME can benefit from being bundled, but it's mostly developers
who want to provide a single bundle for all glibc distros that will benefit
in this regard.

The security aspect is real though since I also don't want all network
clients to have access to all of $HOME. How do you know that Dropbox
doesn't secretly copy your ~/proprietary-work-for-boeing folder?
Whitelisting what networked apps have access to in the filesystem is
very important.

Another very useful case would be using containers as a chroot replacement
for having clean (only what's in the recipe), reproducable build environments
for building arch packages. It would also allow installing makedeps only in
the container/chroot or make cross-compilation easier to manage.

Are there plans to support this in makepkg? I believe xbps has this.