Re: xwallpaper: a pledged wallpaper utility

[Juan Francisco Cantero Hurtado]

On Sat, Apr 01, 2017 at 11:43:04AM +0200, Tobias Stoeckmann wrote:
> Hi misc@,
> 
> during the last weeks, I have reviewed quite some image tools out there
> because I needed one to set a wallpaper on my X server. I am not using
> a sophisticated desktop environment, so there was a need for a
> standalone tool. Let's keep it short: I have found and reported many
> bugs, and had to stop eventually after accepting that these libraries
> are either legacy/unmaintained or beyond repair (calling printf and free
> in signal handlers, anyone?).
> 
> To overcome this issue, I decided to write a simple utility, with the
> common OpenBSD focuses: Simplicity, security, doing exactly one thing.
> 
> The tool supports three file formats:
> 
> - JPEG; virtually everyone uses it
> - PNG; most popular lossless format
> - XPM; well, it's the most common agreement on X installations out there
> 
> I still want to be able to zoom into my pictures, so these modes of
> operations are supported:
> 
> - tile; tiles the image next to each other until screen/output is filled
> - center; centers the image
> - maximize; maximizes the image without cutting things off
> - stretch; destroys aspect ratio and fills the whole screen/output
> - zoom; maximizes the image and cuts things off, screen/output is filled
> 
> To get nice results, xwallpaper directly uses pixman for pixel
> operations. In case you don't know pixman: It is the direct foundation
> for the xorg-server to do pixel operations. No further dependencies!
> 
> Next to this, it avoids using the old (deprecated) X11 libraries. Found
> bugs in them as well and also got repeatedly told that they are not
> supposed to be used anymore either. So I decided to go with XCB.
> 
> Multi monitor setups are too regular by today to completely ignore them
> or using Xinerama with its weird numbering. Instead, it uses RandR if
> available, which makes it pretty nice to use. It even supports different
> modes (tiling, centering etc.) on different outputs! And if you are used
> to run xrandr, the syntax will be very familiar.
> 
> Last but not least, the tool is tightly pledged. We all know that file
> formats suck and they contain lots of bugs. For increased security, I
> have included pledge support right from the start. Before even one
> instruction of one of these image libraries is called, pledge is already
> down to "stdio". That's really tight! :)
> 
> All in all, it can be compiled with 0 dependencies with xenocara. Keep
> in mind that you just have XPM support then, though.
> 
> It's not in ports (yet?). It would be really great if you can give it a
> try, experiment a bit, and give me feedback. If you are an XCB expert
> and/or into code reviewing: Please do so! And if you have a big endian
> machine, it would be great if you can see if it works there as well.

The program works fine on macppc with a png image.

> 
> The project as well as its release files can be found on GitHub:
> https://github.com/stoeckmann/xwallpaper
> 
> 
> Hope someone finds this tool useful, too.

Are you going to create a port for xwallpaper?


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: AMD Ryzen

[Adam Van Ymeren]

Sorry, I guess I read more snark in your message then was actually there. I
apologize.


 Original Message 
From: Karel Gardas 
Sent: April 1, 2017 2:33:07 PM EDT
To: Adam Van Ymeren 
Cc: OpenBSD general usage list , Damian McGuckin

Subject: Re: AMD Ryzen

On Sat, Apr 1, 2017 at 4:17 PM, Adam Van Ymeren  wrote:
>
>
> On April 1, 2017 8:02:07 AM EDT, Karel Gardas  wrote:
>>If you do have hardware available, why you just don't attempt to boot
>>latest snapshot? Should take you just few minutes and then you can
>>even report here together with dmesg output about your experience...
>
> Could be he's debating purchasing hardware.  Damn this list can be snarky.

If so, then I clearly misunderstood OP's "Just curious whether it is
worth the effort to try." -- well, not native English speaker here.
Anyway, being snarky was not my idea...

Re: AMD Ryzen

[Karel Gardas]

On Sat, Apr 1, 2017 at 4:17 PM, Adam Van Ymeren  wrote:
>
>
> On April 1, 2017 8:02:07 AM EDT, Karel Gardas  wrote:
>>If you do have hardware available, why you just don't attempt to boot
>>latest snapshot? Should take you just few minutes and then you can
>>even report here together with dmesg output about your experience...
>
> Could be he's debating purchasing hardware.  Damn this list can be snarky.

If so, then I clearly misunderstood OP's "Just curious whether it is
worth the effort to try." -- well, not native English speaker here.
Anyway, being snarky was not my idea...

Re: xwallpaper: a pledged wallpaper utility

[Bryan Steele]

On Sat, Apr 01, 2017 at 11:43:04AM +0200, Tobias Stoeckmann wrote:
> Hi misc@,
> 
> during the last weeks, I have reviewed quite some image tools out there
> because I needed one to set a wallpaper on my X server. I am not using
> a sophisticated desktop environment, so there was a need for a
> standalone tool. Let's keep it short: I have found and reported many
> bugs, and had to stop eventually after accepting that these libraries
> are either legacy/unmaintained or beyond repair (calling printf and free
> in signal handlers, anyone?).
> 
> To overcome this issue, I decided to write a simple utility, with the
> common OpenBSD focuses: Simplicity, security, doing exactly one thing.
> 
> The tool supports three file formats:
> 
> - JPEG; virtually everyone uses it
> - PNG; most popular lossless format
> - XPM; well, it's the most common agreement on X installations out there
> 
> I still want to be able to zoom into my pictures, so these modes of
> operations are supported:
> 
> - tile; tiles the image next to each other until screen/output is filled
> - center; centers the image
> - maximize; maximizes the image without cutting things off
> - stretch; destroys aspect ratio and fills the whole screen/output
> - zoom; maximizes the image and cuts things off, screen/output is filled
> 
> To get nice results, xwallpaper directly uses pixman for pixel
> operations. In case you don't know pixman: It is the direct foundation
> for the xorg-server to do pixel operations. No further dependencies!
> 
> Next to this, it avoids using the old (deprecated) X11 libraries. Found
> bugs in them as well and also got repeatedly told that they are not
> supposed to be used anymore either. So I decided to go with XCB.
> 
> Multi monitor setups are too regular by today to completely ignore them
> or using Xinerama with its weird numbering. Instead, it uses RandR if
> available, which makes it pretty nice to use. It even supports different
> modes (tiling, centering etc.) on different outputs! And if you are used
> to run xrandr, the syntax will be very familiar.
> 
> Last but not least, the tool is tightly pledged. We all know that file
> formats suck and they contain lots of bugs. For increased security, I
> have included pledge support right from the start. Before even one
> instruction of one of these image libraries is called, pledge is already
> down to "stdio". That's really tight! :)
> 
> All in all, it can be compiled with 0 dependencies with xenocara. Keep
> in mind that you just have XPM support then, though.
> 
> It's not in ports (yet?). It would be really great if you can give it a
> try, experiment a bit, and give me feedback. If you are an XCB expert
> and/or into code reviewing: Please do so! And if you have a big endian
> machine, it would be great if you can see if it works there as well.
> 
> The project as well as its release files can be found on GitHub:
> https://github.com/stoeckmann/xwallpaper
> 
> 
> Hope someone finds this tool useful, too.

It does what it says on the tin, really handy. Thanks for sharing.

> Tobias
>

-Bryan.

Re: AMD Ryzen

[Adam Van Ymeren]

On April 1, 2017 8:02:07 AM EDT, Karel Gardas  wrote:
>If you do have hardware available, why you just don't attempt to boot
>latest snapshot? Should take you just few minutes and then you can
>even report here together with dmesg output about your experience...

Could be he's debating purchasing hardware.  Damn this list can be snarky.

>
>On Sat, Apr 1, 2017 at 6:24 AM, Damian McGuckin 
>wrote:
>> Has anybody achieved an installation of OpenBSD on this yet please?
>>
>> Just curious whether it is worth the effort to try.
>>
>> Regards - Damian
>>
>> Pacific Engineering Systems International, 277-279 Broadway, Glebe
>NSW 2037
>> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not
>wanted here
>> Views & opinions here are mine and not those of any past or present
>employer

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: OpenBSD httpd and HTTP/2

[Nicolai]

On Sat, Apr 01, 2017 at 03:04:50AM +1100, bytevolc...@safe-mail.net wrote:

> The benefits are there, but I feel it encourages lazy and disorganized
> web development, leading to stupidly bloated and inefficient sites,

HTTP/2 multiplexing is only "effective" when web designers have built
websites without lots of 3rd party content, so IMO HTTP/2 discourages
(this kind of) bloat.  That said, modern web design is in a pretty bad
state.  I don't think web designers have any idea what they're doing, so
in effect HTTP/2 won't lead to better websites.  What needs to happen is
for Google to punish bloated websites.  THAT will get people to care.

Nicolai

Re: AMD Ryzen

[Karel Gardas]

If you do have hardware available, why you just don't attempt to boot
latest snapshot? Should take you just few minutes and then you can
even report here together with dmesg output about your experience...

On Sat, Apr 1, 2017 at 6:24 AM, Damian McGuckin  wrote:
> Has anybody achieved an installation of OpenBSD on this yet please?
>
> Just curious whether it is worth the effort to try.
>
> Regards - Damian
>
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer

xwallpaper: a pledged wallpaper utility

[Tobias Stoeckmann]

Hi misc@,

during the last weeks, I have reviewed quite some image tools out there
because I needed one to set a wallpaper on my X server. I am not using
a sophisticated desktop environment, so there was a need for a
standalone tool. Let's keep it short: I have found and reported many
bugs, and had to stop eventually after accepting that these libraries
are either legacy/unmaintained or beyond repair (calling printf and free
in signal handlers, anyone?).

To overcome this issue, I decided to write a simple utility, with the
common OpenBSD focuses: Simplicity, security, doing exactly one thing.

The tool supports three file formats:

- JPEG; virtually everyone uses it
- PNG; most popular lossless format
- XPM; well, it's the most common agreement on X installations out there

I still want to be able to zoom into my pictures, so these modes of
operations are supported:

- tile; tiles the image next to each other until screen/output is filled
- center; centers the image
- maximize; maximizes the image without cutting things off
- stretch; destroys aspect ratio and fills the whole screen/output
- zoom; maximizes the image and cuts things off, screen/output is filled

To get nice results, xwallpaper directly uses pixman for pixel
operations. In case you don't know pixman: It is the direct foundation
for the xorg-server to do pixel operations. No further dependencies!

Next to this, it avoids using the old (deprecated) X11 libraries. Found
bugs in them as well and also got repeatedly told that they are not
supposed to be used anymore either. So I decided to go with XCB.

Multi monitor setups are too regular by today to completely ignore them
or using Xinerama with its weird numbering. Instead, it uses RandR if
available, which makes it pretty nice to use. It even supports different
modes (tiling, centering etc.) on different outputs! And if you are used
to run xrandr, the syntax will be very familiar.

Last but not least, the tool is tightly pledged. We all know that file
formats suck and they contain lots of bugs. For increased security, I
have included pledge support right from the start. Before even one
instruction of one of these image libraries is called, pledge is already
down to "stdio". That's really tight! :)

All in all, it can be compiled with 0 dependencies with xenocara. Keep
in mind that you just have XPM support then, though.

It's not in ports (yet?). It would be really great if you can give it a
try, experiment a bit, and give me feedback. If you are an XCB expert
and/or into code reviewing: Please do so! And if you have a big endian
machine, it would be great if you can see if it works there as well.

The project as well as its release files can be found on GitHub:
https://github.com/stoeckmann/xwallpaper


Hope someone finds this tool useful, too.

Tobias

Topics for revised PF and networking tutorial

[Peter N. M. Hansteen]

Hi,

I thought I'd like to give you a heads up that there will be a "PF and
networking" tutorial at BSDCan 2017 in Ottawa this June.

The session will however not be the Nth rerun of the old one, we're
starting from scratch this time, and were looking for input on what to
include.

Do you have questions on PF and related matters, or are there specific
topics you would like to see covered?

We want to hear from you, either contact us directly at the reply-to
address use the list.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: OpenBSD httpd and HTTP/2

[Janne Johansson]

2017-03-31 13:30 GMT+02:00 Marina Ala :

> UDP servers listening? would that open possibility for massive DOSes?
>


QUIC does make sure the client initial UDP packets are larger than the
response until some secret handshakes are completed,
so a QUIC webserver won't be a good amplifier, even if it could be used to
anonymise UDP response packets.

-- 
May the most significant bit of your life be positive.

Re: Is there something to replace zaurus?

[Paolo Aglialoro]

Some years ago got an acer One with N270, broken 8GB ide ssd (those 1st gen
rubbish) which "run" linux on 512mb.

Substituted it with a 1.8" 30gb hd (and filled up its 2 SD slots), expanded
to 1.5gb ram, reworked chassis to host an external sna connector for big
antenna.

This machine, which still today can run modern linux, runs openbsd
marvellously, has a wonderful screen and keyboard. Also, with a new 9 cells
battery lasts incredbly like a porno actor.

Till it runs i won't detach from it :)



Il 01/apr/2017 06:47 AM, "Ax0n"  ha scritto:

> Until I really wanted to mess with vmm(4) late last year (thus requiring me
> to move to a more portly i5 laptop), my daily driver was a Toshiba NB305,
> on which I've run OpenBSD since 2011. It still comes out to play whenever I
> need excellent battery life and/or a light carry load-out. Everything from
> WiFi to screen brightness, volume control and suspend worked out of the box
> with OpenBSD back then, and still does today. I max'd it out to 2GB of RAM.
> Gmail in Chromium and/or Firefox is usable. HTML5 videos play fine on
> YouTube in Chromium. But I wouldn't call it an enjoyable experience by any
> stretch, but OpenBSD runs better on that old thing than Windows 7 starter,
> Ubuntu, Arch or Debian ever did.
>
> GeminiPDA (I won't link to it here) has piqued my interest, but if it comes
> to fruition the way many crowd-funded hardware projects go, I am not
> holding my breath for OpenBSD on it. I have a small fleet of HP Jornadas
> (mostly 720s) that run NetBSD/hpcarm well, and the Gemini seems like it
> would scratch that itch for something similar in stature with more than 205
> MHz and 32MB of RAM.
>
> On Fri, Mar 31, 2017 at 10:20 PM, Nick Holland <
> n...@holland-consulting.net>
> wrote:
>
> > On 03/29/17 05:51, Luke Small wrote:
> > > I thought I read that there is an arm7 based mobile device, but I can't
> > > find anything about it.
> > >
> >
> > Not quite as tiny, but in more capable in almost every way are the
> > netbooks of a few years ago.  In addition to being small and portable,
> > they can have real networking (wireless (sometimes with a hw swapout)
> > and wired), several USB devices attached, huge (relatively speaking)
> > disks installed, lots of RAM, usable keyboards, etc.
> >
> > With lots of patience (and some swap), can even run modern browsers on
> > them.
> >
> > Nick.

Re: malloc.conf recommended settings

[Otto Moerbeek]

On Sat, Apr 01, 2017 at 03:11:32AM +, Steven Schneider wrote:

> Hi,
> 
> I have a question about the recommended settings for /etc/malloc.conf.  I'm
> currently using JUC on my i386 laptop, just to see how the old beast handles
> it. I hadn't noticed any significant performance issues though it did crash
> Chromium because it was using memory it had just freed. On my amd64 desktop
> I am just using J as I was working on some assignments and I didn't want to
> try anything too risky until I had completed the assignments.

I'd use at C or S for development. The earlier you discover a problem,
the better. Note that S includes a few other flags.

> 
> What are some recommended settings for /etc/malloc.conf in given scenarios
> such as general use desktop, or an internet facing webserver?

Just use no malloc.conf, it's te default. If the performance loss is
acceptable (only you can decide that) try S. But as you have seen,
some programs have bugs that are exposed by the flags. Again, only you
can decide if that's acceptable.

-Otto