Re: Will future programmers probably warn people not to use high-level programming languages just as most programmers today warn people not to use assembler?

2019-10-29 Thread Nathan Hartman 
On Tue, Oct 29, 2019 at 7:41 AM Clark Block  wrote:

> Just as most programmers today warn people not to use assembler, probably
> future programmers will warn people not to use high-level programming
> languages.


In the future, computers will program programmers.

Re: SCM

2019-07-28 Thread Nathan Hartman 
On Sun, Jul 28, 2019 at 3:27 PM Stefan Sperling  wrote:

> On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote:
> > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I
> > root for Subversion.
>
> Vetoed, for 3 simple reasons:
>

(snip)


>  3) I don't want to be held responsible when it breaks on Theo
>

THAT is definitely a valid reason!

Re: SCM

2019-07-28 Thread Nathan Hartman 
On Fri, Jul 26, 2019 at 8:31 PM Австин Ким  wrote:

> I can't argue with that, and obviously code quality is infinitely more
> important than what SCM you use, but I feel you run the risk of turning off
> potential new developers coming out of colleges and universities who cut
> their
> teeth on distributed SCM systems like hg and Git who might be taken aback
> at
> why the Project is still stuck with CVS (and again, I am not advocating for
> Git; though if it isn't obvious by now I really believe OpenBSD developers
> would honestly like Mercurial; to me it just seems consistent with
> OpenBSD's
> culture of cleanliness and simplicity).


One can cut one's teeth on git and believe whatever one wants to
believe but SCMs are not one-size-fits all.
* Distributed does not mean better.
* Centralized does not mean worse.
* CVS does not mean "stuck."
* Git does not mean smart.
* Hg does not mean Au.

Every project has its own requirements and should use the tools that
fit best.

*IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I
root for Subversion. Subversion offers the following advantages:

1. CVS's closest relative; fixes all of CVS's shortcomings.
2. Very easy to learn and use. You practically can't screw it up.
3. Immutable history, i.e., SAFE to use.
4. Handles a giant repository with ease. (Many git projects fracture
   into numerous repositories to work around git limitations, so you
   lose atomic commits and get a maintenance headache instead.)
5. Sparse checkouts.
6. Versioned properties attached to files and directories (git can't
   version directories).
7. Follow history through copies, moves, and renames.
8. Coded in C89. Very few dependencies.
9. Apache license. Not BSD but much closer than any GPL revision.

I'm sure you've heard bad things about Subversion. These old myths and
facts stopped being true a decade ago.

Re: SCM

2019-07-22 Thread Nathan Hartman 
On Mon, Jul 22, 2019 at 11:49 AM Ingo Schwarze  wrote:

> Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400:
>
> > CVS for source code management.
>
> That's kind of a frequently asked question.
>
> Some of us (including myself) actually prefer CVS over git for tasks
> where it is suffiecient because KISS.
>

I always assumed that the OpenBSD devs have audited the heck out of
CVS for security issues and are sticking to it for that reason.

KISS is a very valid reason though.

If the project ever did decide to switch, the closest cousin of CVS
is SVN, not hg, git, fossil, etc. Apache license...

Re: OpenBSD Project

2019-07-21 Thread Nathan Hartman 
On Sun, Jul 21, 2019 at 12:40 PM Theo de Raadt  wrote:

> Perhaps the reason it has worked so long is because we don't have a
> sentence like this, which some may consider contentious, and use as
> reason to pick yet another infamous fight where they believe they know
> better than a quarter decade old project?


Quarter century.

Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-09 Thread Nathan Hartman 
On Tue, Jul 9, 2019 at 2:43 PM Marc Espie  wrote:

> - we do use gzip because other compression systems won't work with little
> memory/don't have the right licence.


You might find this interesting:

https://github.com/silentbicycle/heatshrink

Re: OT: hardware war with manufacturers (espionage claims)

2019-07-02 Thread Nathan Hartman 
On Tue, Jul 2, 2019 at 1:28 PM Brian Brombacher 
wrote:

> Oh and if the implant is smart, it’ll detect you’re trying to find it and
> go dormant.
>
> Even more good luck!


Well then the solution is obvious.

Design your own hardware.

Or learn to live off the land.

Future of X.org?

2019-06-28 Thread Nathan Hartman 
Came across this:

https://www.phoronix.com/scan.php?page=news_item=X.Org-Maintenance-Mode-Quickly

Long story short, Red Hat hopes to switch from X.Org to Wayland and
expects X.Org to go into "hard maintenance mode" after that.

Relevant to OpenBSD?

Re: single user question

2019-05-17 Thread Nathan Hartman 
On Fri, May 17, 2019 at 12:28 PM ropers  wrote:

>
> In the history of the (Berkeley) Fast File System, has there ever been
> an attempt to implement DOS-like undelete for FFS/UFS?
> (I understand that for technical reasons, this could require running a
> daemon that remembers just enough metadata to keep data recoverable so
> long as it's not overwritten. I also understand that running a daemon
> that remembers things nominally deleted would have security
> implications, which may not keep me from running a daemond that w/o
> being perfect could protect me from myself at least some of the time.)
> I did find this:
> https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271785.html
> -- which didn't seem to suggest that the answer was any yessier now
> than thirty years ago. So, that's a no, then? Anyone? Bueller?


Maybe that could work for "normal delete" while making available a separate
"secure delete" that cannot be un-deleted and furthermore overwrites the
deleted data with random garbage. Administrators could optionally force the
secure overwrite delete.

>

Re: When will be created a great desktop experience for OpenBSD?

2019-05-13 Thread Nathan Hartman 
On Mon, May 13, 2019 at 1:26 PM Steve Litt 
wrote:

> As I travel this earth I continue to be amazed at peoples' fascination
> with tiny fonts. Perhaps that's to pack more stuff on the screen. But
> then they go on to make the text low contrast in the name of "pretty",
> thereby locking out those who can't correct to 20/20. And just to rub
> salt in the wounds, they always make their tiny black background
> terminals transparent, so random noise can confuse further.
>
> SteveT


I am similarly amazed.

User interfaces have gotten progressively
worse over the last 15 years and the trend
continues.

>

Re: Research and OpenBSD: How can I help?

2019-02-20 Thread Nathan Hartman 
On Tue, Feb 19, 2019 at 9:35 PM Frank Beuth  wrote:

> On Thu, Feb 14, 2019 at 04:22:05AM +, Paul Swanson wrote:
> >Are there particular problems that could benefit from new
> >ideas or solutions?
>
> An area that I am personally interested in is running OpenBSD on fully
> open-source / binary-blob-free hardware: hardware where there is no
> proprietary
> firmware that could hide vendor backdoors, and ideally where even the
> design of
> the chip is available to the user for review.
>
> The trouble is it's VERY hard to find "fully open" hardware, and the
> hardware
> which is known to exist (loongson, OpenPOWER, RISC V) is difficult to get,
> expensive or not very good, and (except for loongson) not supported by
> OpenBSD.


Might be time to learn FPGAs! :-)

Re: console radeondrm default font change

2019-01-06 Thread Nathan Hartman 
On Sun, Jan 6, 2019 at 3:20 PM Mihai Popescu  wrote:

> https://www.cambus.net/spleen-monospaced-bitmap-fonts/


Wow that is a beautiful font.

Re: Porting some software to OpenBSD

2019-01-05 Thread Nathan Hartman 
On Sat, Jan 5, 2019 at 10:27 PM Adam Steen  wrote:

> Hi All
>
> I have a question about string (printf) formatting.
>
> I have a variable
>
> 'uint64_t freq'
>
> which is printed with
>
> 'log(DEBUG, "Solo5: clock_init(): freq=%lu\n", freq);'
>
> but am getting the following error
>
> '
> error: format specifies type 'unsigned long' but the argument has type
> 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
> freq);
> ^~~~
> 1 error generated.
> '
>
> The easy fix is to change the format to '%llu', but this brakes FreeBSD
> and Linux. Am i missing something or should i be investigating the log
> implementation?
>
>
> Cheers
> Adam


There are often subtle differences like this between platforms.

One possibility is to define preprocessor macros that expand to the correct
printf format modifier for the platform. I've seen several implementations
over the years. One that comes to mind (only because I saw it recently) is
pstdint.h:

http://www.azillionmonkeys.com/qed/pstdint.h

(I don't know if that works correctly on OpenBSD. Also it defines a bunch
of other things; that may be helpful, or unhelpful!)

A more fully featured library that deals with platform differences is APR,
the Apache Portable Runtime. I think there are also such definitions there.