My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Friday, March 20, 2015

Semi-bright Spots for Developing on-the-go on Google's Android

I have a friend who is augmenting his standard of living in seriously positive ways writing apps for iOS. I commented that I have not been happy with Apple since they got in bed with Intel on the switch.

(Would not have minded if they hadn't been binary about the switch, if they had simply added Intel models and not dropped the PowerPC processor. Would mind less if there were AMD models. Would mind much less now if I could get a usable development capable workstation running (Mac OS, I assume) on a 64 bit ARM processor.)

He replied that Google has become the new Microsoft.

Yeah, Google is going the way of all big companies. We know that.

Going big is going bad. WordPerfect fell into that trap, didn't they? I expected Google to go downhill.

He encouraged me to get an Android tablet anyway and start learning to build apps on it. He was right, and I did, and I have been digging into developing on/for it. It's definitely more of a mess than the iOS, but that's to be expected, too. Open source software is software developed by committee, and it may be the best way that committees can and should work, but the lack of focus shows through.

Found some sort-of bright spots, but the shine doesn't last.

Up front, before I go full-negative here, the Android device is a nice portable mailbox. Gmail is improving, and I really should try out some of the 3rd-party mail apps. It's also a very nice box for reading scriptures on the train. Google maps is really handy, although my portable router gets plugged up and kicked off the telephone network rather quickly. Not sure why.

But everything is so half-baked. Here are some of the frustrations I'm working against at the moment:

** Even the math/algebra/geometry app Geogebra has the UI hog-tied (in the Android version, because of lack of mouse and real keyboard, I assume). (Slightly unfortunate name, that. Would Algeobramathetry have been better? And there is a Japanese site.)

But I really wish they weren't deluded into thinking that everyone has all-day connection and that saving to their servers is somehow better than saving to the user's own disk drive.

** The text editor Jota has gone, how can I say this politely? connected. You get ads from Google when you run it, unless you pay for it. Seems reasonable, except that a text editor should never have any reason to connect to the network internally.

Externally, yes, it's nice to hook the file save/load dialogs into the system's networking functions. Not internally. Instead, by external connection that I have to initiate myself.

When I'm writing in my journal, some of that is so un-processed that I wouldn't even want myself to have access to it, if I could avoid that. And if the text editor is getting ads unless I pop for the low-low use fee, how do I know that it is not copying my keystrokes to the web even if I pay the low-low use fee?

Functionally, it's pretty nice, and getting better. But I can't trust it to use for the things I most need a text editor for.

And Jota is the best text editor I've been able to find so far.

And all the others do the same thing about ads.

** The file manager Astro has the same problem, too. It's a little funky about how you dig around in your file system because, I suppose, of the fake walls Google helps the vendor put up, making a show of protecting your data. But the real sin here is the connected "functionality". The "Free Astro Backup Account" and the "Rate Us".

Again, I can't trust it for what I need it most for.

** Raised my eyebrows just now when I updated the LDS Gospel Library and it asked for access to my profile.

Why should it need that? If it really does need something out of there, Google has done a poor job of normalizing the storage of my profile.

** Oh. Yeah. Google has done exactly that. That's one of the reasons my friend called them the new Microsoft. Cutting corners as a way to increase access to potentially profitable stuff.

(Hmm. Is there a way for an app to tell me that it is giving back access that the developers realize they don't need after all?)

** Basically, all the apps that fill in the functionality that the vendors have stripped out have the same problem. Trying to force the revenue stream. Succumbing to the temptation to over-reach in functionality.

There would be no problem if the developers for these apps offered external integration to for-pay backup space and such, say, a way to use the file access dialogs to save and load across the network.

But the functional integration is gratuitous, gets in the way of using the apps as tools, and breaks the agreement of trust.

Apps should do the minimum, and delegate the rest. That's the way they can be trusted.

Moving on to some of the more developer-oriented tools:

** The wireless keyboard loses connection and bounces. Really hard to get stable text entry with it on the train or anywhere else there is a lot of wireless traffic.

Bluetooth is such a ... . Well, I don't have nice things to say about bluetooth. You should not consider bluetooth a feature. Call it a blob of misfeatures.

** Gforth is nice.

Unfortunately, it tends to go pop every now and again. Sends you to the Android equivalent of a desktop, and when you go back, your session is gone.

The keyboard and non-ASCII characters seem to be some of the issues here. The pseudo-walls also cause problems, and not being run from a real shell causes more.

Actually, if I weren't busy with my own projects, gforth on Android is something I would be focusing on. It is definitely one of the brighter spots. Cool stuff here, and they need more of a user community.

** No-root Debian is nice, but you do need a hardware (USB) keyboard and mouse to do any serious work, and it goes pop every now and then like gforth does. Probably for similar reasons.

Trying to edit code in it on the train has not worked well for me. But I've been able to walk it through compiling code on the train, even with the software keyboard. Cool? Yeah.

bc and gforth run nicely enough.

A little bragging on myself, my 6800 assembler and my bif-c implementation of forth compile and run well enough on no-root debian. (Need to try compiling Joe Allen's exorsim on no-root debian sometime, or write my own 6800 simulator.)

Now this is not your free ticket to editing the system files. It's subject to the same pseudo-walls as all the apps that play "nicely" in the Playstore sandbox.

** terminal-ide is useful for understanding what's going on under the hood. It is subject to the sandbox rules like no-root debian, but the help functionality gives you a bit better view of what's happening on the tablet when you are working with the Google-provided hosted developer tools.

Working with an incomplete set of libraries, and without a true shell, is not exactly productive. I haven't been able to get the 6800 assembler to produce object code, nor have I been able to get the bif-c interpreter to give me a command prompt before segfaulting.

Not even thinking of trying to compile bc yet.

** Google's hosted developer tools are, well, developer level. Steep learning curve.

The biggest disappointment was trying to get admin-level access to my Acer tablet. I won't comment more on that until I buy a Nexus and try again, to make sure it wasn't just me.

The developer tools don't run well on openbsd. I don't want to use Linux any more after various things (such as /usr, and uefi) in the flap surrounding the systemd fiasco made it obvious that Linux is subject to social engineering. But I'll probably have to get a dedicated dev box with some sort of Linux running, if I decide to get serious about getting my own apps running on Android tablets.

Whether I do that before I buy a Mac and an iPad and start digging into iOS, I'm not sure.

Ask for help getting the android dev tools working on openbsd on the misc@ list,
and you'll get laughed at and accused of selling your soul.

Which is as it should be.

---------

I hear Android 5.0 brings back users.

You say, "WHat?"

User login. Where you have a user name that you choose and an associated password.

On Android, until Android 5.0, the idea was that everyone would not want the bother of managing users on a portable phone.

Stupid idea. If you want to lend your phone to a friend, you probably don't want to lend your friend your private phone book. And, for mixing business and personal use on the same phone, well, that's the data sink that feeds about half of the spam between PCs running Microsoft's OSses. Ticking time bomb.

And so much mistaken security effort induced by that one bad decision, trying to re-work the (correct) security model of *nix systems into an (incorrect) model that just ended up needing to be fixed.  And all the phones that have been sold with the engineering error, and all the vendors who are unwilling to provide upgrades to Android 5 for their hardware.

Until I see for myself whether Android 5 has actually brought real user logins or just gone further down the road of trying to re-invent things that were done right to start with, just so managers could pretend they were being productive without really doing anything, I can't say whether things have actually been fixed.

---------

The GPL and all other true open-source licenses are legal implementations of something called an "agreement between gentlemen".

Simply put, there are rules to business. Treat each other nicely or drown in the cesspool of your own making. And when you are drowning, well, if it's your greed that is part of what is filling the cesspool, don't be surprised if everyone else is too busy trying to float in a mixture that is less dense than they are to help you.

(You do understand the real danger of cesspools? It's not the smell. It's that the human body, which floats somewhat well in clean water, sinks in a cesspool.)

The gentleman's agreement is that we play the games, but we don't go too far. When we see someone going too far, the agreement allows us to kick the recalcitrant in the seat of the pants to get his attention. If necessary, it allows us to kick the consistent offenders out of the game. Not just allow it, require it.

With open source licenses, the license helps us talk about figuring out what going too far means:

  • Take, but give back.

  • Don't build and sell stuff intended to be used once and thrown away. 

  • Support your customers. 

  • When you aren't able to support your customers, allow them to support themselves.

  • Most of all, don't demand that your customers get approval for every little thing they want to do with the product they have been kind enough to buy from you.

Take. But give back.

That's how real value is generated. When we give back, if we give for real, we don't lose anything real, but the surrounding community gains more than we give.

That's the first law of economics.

Applied to free OSses like Android and Linux and the BSDs, if you are making money from them, support the developer communities with money, code, and especially infrastructure.

Publish your source code, including those no-they-aren't-really-your-crown-jewels drivers, of course.

Set up the infrastructure and support crew (cough, Darwin, Apple?) for open work on the software that makes your business model work.

Not just Apple, of course.

My first cell phone was a Docomo-branded Panasonic running a Limo/Tizen OS. Somewhere in the documentation was a link, and I found, somewhere on docomo's servers, a tarball that claimed to contain the source code that was their "compliance" to the GPL. I never was able to unpack that tarball in any meaningful way before that phone died.

That's not compliance. Bare minimum compliance would have been a link to a page that would
  • tell a competent end-user how to find the community and join it,
  • tell a competent end-user what kind of system was necessary to get at the source code,
  • describe how the competent end-user could set himself up with a system to do at least some useful custom work on the phone without eating more than half a month's pay check
  • in addition to a tarball (but better an open source tree) that could be opened by standard tools.
Maybe I didn't need to know how to get a shell on that phone. But it would have been really useful if I could have used my Java skill to produce a rudimentary stopwatch, among other things. And there were some other things that I have fought with that could have been solved fairly easily with access to a shell.

My new phone is a Docomo-branded Sharp built phone. (I plan to give it to my daughter shortly.) It has problems, and I could solve some of those problems with shell access. I haven't bothered looking for the compliance tarball for it, probably will not bother.

When I talk about such things at the Docomo service centers, if the service rep knows what I'm talking about, there's a look in her eyes that should be reserved for when she sees a terrorist.

If the wireless phone network is that vulnerable, I'm not the problem, the phone company itself is.

What is the difference between Limo/Tizen and Android?

Google did a better job of telling interested developers how to get started.

That's about it.

But there's still something missing.

When I got this Acer brand Android tablet, it was still at Android 3.2 or so. Acer provided an update to Android 4. That is, they provided a binary update.

I found some source code on Acer's site, but I am not optimistic about being able to use it. None of the mainstream Linux distributions or *BSD OS communities have it in their repositories, because it is really hard to integrate the code into their trees and workflows. And it's hard to get the hardware, and hard to get the hardware set up to reliably test the OS that results.

If they are going to be able to use this source code, they need more help from Acer and Google. This is where things shift from the taking phase to the giving phase.

They need Google and Acer to assign an engineer to help them get the code integrated into their source tree. And they need test hardware.

NO WAY!!!!!!! you say. No company is going to waste valuable engineering time on supporting non-product!

This is where you shift from taking to giving, Google. All the billions you have in the black, surely you could give up maybe ten thousand of dollars worth of engineering time. And a pair of each of the current model Nexus tablets to the Fedora, Debian, and Ubuntu communities, and to the FreeBSD, netBSD, and openBSD communities wouldn't even begin to hit your bottom line.

That would provide enough to provide a way to keep these tablets useable even after the maker quits providing Android updates. It would also help the makers figure out how to set up user support communities for Android on their products, which is where it comes back around to strengthen your bottom line.

That's what is missing in Android. Just because Apple is being a pig is no excuse.

Thursday, February 26, 2015

Skating Mashup on White Rock

Chasing around in memories of progressive rock.

Looked up Rick Wakeman's White Rock and found this mashup of The Shoot and Olympic performances by Tessa Virtue and Scott Moir on youtube.

And I'm distracted by the confllicts between law, courtesy, and art. I'm sure Rick Wakeman wouldn't mind, and I imagine Tessa Virtue and Scott Moir might be pleased. Maybe.

It's the Olympics committees I'm worried about.

Courtesy is owed, but it should not be forced.

Art is art.

Tuesday, February 3, 2015

To the Girl on the Train

(One of those had-a-bad-day riffs, still not sure whether I should post it.)

You got legs.
Pretty legs.
And a skirt to show them off.

Well I can see you got legs.
It's not my business, how beautiful they are,
It's not something I wanted to know.

I got eyes.
Bad eyes.
They only see what's in front of them,
And that, none too well.

If I see your legs in that skirt you're wearing,
Is it my fault or yours?

I don't know.

Fashion, what you wreak in men!
What you wreak in women!

I was already distracted,
My thoughts gone far afield
To arcane mathematical hobbies,
And now I see your legs.

You got needs.
I can see your needs in the fashion you wear.

But I'm not one to see your legs
And I'm not one to know your needs.
Will you pardon me
If I turn my eyes away?

[Really hadn't wanted to channel ZZ Top today.]

Monday, January 5, 2015

What WordPerfect Corp Should Have Done in the 1980s (or, the Reasons They Did Not Hire Me)

A question about running Unix WP 5 on a modern Debian system brought back some ancient memories.

I was at BYU in the mid-'80s, when WordPerfect was becoming the standard word processor. I knew the guy who managed the Macintosh version development for the first several years. Took classes from one of the founders of the company. Etc.

Tried to get a job there. I was headed in a different direction than they were, so they turned me down.

One of Satellite Software International's products was a FORTH language system which I used (not very effectively) as an intern at IBM when I was recovering from a broken engagement in 1986 or so.

(Heh. As I write this, the English wikipedia page on WordPerfect has it as Satellite Systems International, which is a completely different company. The Japanese page has it correct. There's one kind of bit rot.)

My memory is that Dr. Ashton once said, in class or lab, something about early versions of WordPerfect being implemented in FORTH, and that the C code base had a lot of FORTH-isms for quite a while. (This would not be surprising. FORTH, like LISP, is structured well for text stream processing, which is a lot of what made WordPerfect such a successful product.)

If I could have gotten Dr. Ashton's ear --

Never saw Bruce Bastion on campus that I remember, but I did have some opportunities to talk with Dr. Ashton, since I took a class from him. I tried to talk FORTH and the 6809 up to him. Didn't find out about their FORTH language system product until some time after that class. This was just another example of the social, political, market, non-technical stuff going on at the time, and my studied cluelessness.

I daydreamed while doing my homework, about getting into that company and building a "WordPerfect PC" using the 6809 or the 68000. About re-writing, as I assumed, the code in FORTH, and thus making it possible for the customers to add custom modules.

About using WordPerfect and a canonical WordPerfect Personal Computer as a wedge to push a new cross-platform freedom-enabling OS based on constructing a Unix-like system on the foundations of FORTH as a run-time and library model.

I was enamored with FORTH. They were moving the code base for WordPerfect along on standard C.

-- Don't get me wrong. I like C, to play with. It's lacking in certain features to support large projects, and C++ and Java only manage to point their fingers sort of in the right directions.

-- And not that FORTH did/does not need extending to handle some of the things that C handles well. But FORTH has the extensibility that C still lacks. (And I know that extensibility is a two-edged sword, the tendencies of source code to slip away from standards. And I now have an idea how most FORTH enthusiasts have cut themselves carelessly wielding that sword)

I was interested in the cooperative and open models of software development. They were interested in capitalizing their intellectual property.

I was anxious to set up viable opposition to the Microsoft Way. They were interested in a cozy third-party relationship with Microsoft.

I do not understand why anyone would want to voluntarily enter into a relationship with either Microsoft or Intel. It was obvious to me back then, that both companies were hell-bent on pushing their (quite patently false) claims of being the standard, pushing until they had a de-facto monopoly. And anyone who knows history knows the tyranny of monopolies.

Bell Telephone was the only counter-example of a non-evil monopoly, and the only reason they kept their nose (mostly) clean was that the government was breathing down their back.

There seem to be sirens lounging and singing on the rocks of technology --

Technology can be built into systems. (Computers are the archetype of this.)

Systems are great tools for tying customer relationships.

If you can discover it first, keep it secret, get a patent, you can tie your customers to your technology and then you have a guaranteed revenue stream.

It's a siren song.

These kinds of royal grants have been the tools of tyrants in practically every age, and the wedge they form in the social structures of tyranny has proven to be the most effective and destructive tool in undoing the same tyranny.

Unfortunately, innocent bystanders usually get hurt in the wars that result, by the thousands and millions.

That's the reason the US Constitution said "limited time". Temporary stewardship over part of the intellectual and creative commons, derived from the facts of individually-implemented ambition. None of this nonsense about making property out of the social artifacts of the intellectual domain.

No one was supposed to be able to keep control of their inventions and writings their whole lives.

Otherwise tyranny results.

Well, I was disappointed that people who should have been steeped in the traditions of freedom at BYU should be taking their company right into the heart of tyrannical traditions.

And they weren't interested in an idealistic, naive fourth-year sophomore like me.

Now, who's naive?

I guess we all are.

You know, here's the whole reason idolatry is so strictly discouraged in the Bible:
Systems.

The tyrannical pseudo-religious systems that idols represent.

Until we, as a race, become mature enough to quit worshipping systems, I think God will never let us build a proper computer operating system.

Thursday, December 11, 2014

Typing in Japanese in OpenBSD

Finally got my shiny, new openbsd boxes to let me type in Japanese. It was not hard, after all.

First, I got that tablet that I have complained so much about pointed to the packages directory in a local mirror (This was so I didn't have to log in as an admin user while I browsed the web, really. Didn't have non-admin users for surfing set up yet.):
  • Choose a nearby mirror (In my case, jaist, in Japan).
  • Select a release (5.5 or 5.6 right now).
  • Select the packages directory (folder).
  • Select your architecture (in my current examply, i386, but maybe AMD64 for more modern 64 bit machines).
  • Wait several minutes for that page to load. It's a really long list.
  • Scroll down to the ja-*** stuff and read the package names.
  • Now, in a virtual console (ctrl-alt-F1 through -F4) where you have logged in as a wheel group (administrator) user, type: 
    • sudo pkg_add ja-fonts-gnu
    • sudo pkg_add ja-sazanami-ttf
    • sudo pkg_add ja-mplus-ttf
    • sudo pkg_add ibus-anthy
    as you read the package names out of that list. You'll need to type your administrator user password once or more times in the process.
And that should do the job.

[Really late update (2015.01.05):

Learn more about packages form this page:
http://www.openbsd.org/faq/faq15.html
You'll need to add an application that is capable of taking input through input methods, of course.

gedit and firefox are among the applications in the repository that will accept Japanese now.
]

(There's supposed to be a dictionary access tool, too, but I don't see it yet.)

If you want information on any of those packages before you add them, you can use the pkg_info command:
pkg_info ja-vim
Ignore the advice to mess with your font paths unless you have trouble displaying Japanese fonts when you connect to, say, NHK.

Now, you can start it by opening up your IBus Preferences in your Settings menu in, say, XFCE4. But that doesn't stick when you log out.

I'll update this post when I figure it out or get an answer on the mailing list. (I've seen some conflicting information around the internet, and haven't found something that works, yet.)

[Late update (2014.12.31):

As noted in this post to the openbsd list, getting XFCE4 to run the input method on startup was a lot "easier" than I expected. I found a post in the ubuntu forums which mentioned a Startup Items setting (in Gnome, maybe?). I looked around in the XCFE4 Settings menu and found the "Session and Startup" item.

Go to the "Application Autostart" tab in the Session and Startup dialog. Look for ibus and you won't find it. Click the add button. Add the following command:
/usr/local/bin/ibus-daemon -d
with appropriate name and comments. ("Start input method" and "So you can type in other languages", maybe?)

The "-d" argument appears to be the daemonize directive, in other words, it makes ibus a proper service, so to speak.

Adding these to .xinitrc does not seem to make any real difference for xfce4:
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
but they are recommended.

One more thing before you can type in Japanese, if you haven't done it yet: Log out and then back in. Notice the ibus icon now in your task bar or whatever you want to call it. It looks like a small keyboard with an even smaller globe of the world. In fact, right-click it. Select "Preferences" in the pop-up menu.

In the Preferences dialog, go to the "Input Method" tab. Select an input method (Japanese-Anthy in this case) from the "Input Method" pop-up menu, and click "Add". You have to click the Add button or it won't add the method. (I added "Japanese-Japanese", too, for some reason.)

When you close the dialog, the ibus icon changes to show a Latin "A" and a Kana "chi", which is supposed to indicate that Japanese is switched in.

In brief, for XFCE4:
  • Applications Menu=>
  • Session and Startup=>
  • Application Autostart=>
  • add command "/usr/local/bin/ibus-daemon -d"
and
  • Task Bar=>
  • Ibus Icon=>
  • Preferences=>
  • Input Method=>
  • Japanese-Anthy=>
  • Add
What that does for you in XFCE can be found with a few commands at the terminal:
  • ps wwaux | anthy # to show that the key is ibus
  • grep -R ibus  .
  • vi ".config/autostart/I bus daemon.desktop"
which reveals
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=I bus daemon
Comment=Start ibus when xfce starts
Exec=/usr/local/bin/ibus-daemon -d
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
Playing with that should prove interesting and enlightening.

Gnome and other bloated desktop environments should be similar.

I'll try to add instructions for more minimal stand-alone window managers at some point in the future, but the key should be adding the environment settings and command to start the ibus daemon in the appropriate X11 startup script, such as .xinitrc, etc. If I can spring the time, I'll try to look at other input methods, as well. No promises, however. See what you can do with the information above.

end update]




Wednesday, November 19, 2014

Everybody Wants to Rule the World

A couple of days back, the shiri-tori request on the radio was Tears for Fears' "(Everybody Wants to) Rule the World".

I looked it up on youtube and watched the video again, trying to remember what it once meant.

There was a comment in there, somewhere, something about "those wonderful '80s, when videos didn't have to have anything to do with the lyrics."

No way!

The video was very definitely the lyrics.

"Rule the world." was a meme. But it wasn't about trying to control what other people do.

It was about doing what you wanted, even if you really didn't know exactly what it was you wanted.

Looking cool while you were at it was just extra points.

The last decade or so, we've seen a lot of "[X] Rules". This is the exact opposite.

Controlling others, making everybody else join your project, actually being king of the hill, all of that was minus points.

Ruling the world was about ruling yourself.

Saturday, October 25, 2014

The root problem with systemd (according to me, anyway).

I'm wasting too much time posting on this stuff, but I'm going to try to lay out my complaints against systemd and the way it has been induced into the Linux community.

This comes from an exchange on the debian lists, where a member of the community is asking people to help debug systemd in jessie before the release.

If I could afford the hardware to replace my netbook that is no longer portable, or even if my tablet were not locked down and legally driver-hidden, I would be dual booting and probing for bugs in my spare time between classes and while I'm on the train.
 

Not that I really have any spare time.
 

Someone asked me off-list if I were seeking absolution. I assume the question was relative to my claiming that I don't have the resources to help test.

And that seems to me to be an odd question. Why should I feel anything even approaching guilt or remorse for not wanting to jump onto this train?

But, really, why should I even want to test systemd?
That question still has not been sufficiently answered to justify Red Hat in their completely arbitrary decision to push their community (Fedora) onto this train.

I know that the fact that they did so puts the rest of the larger Linux community in an awkward position. That the debian developer community wouldn't try to find their way around pushing the entire debian community onto the same train is still a significant concern to me.

systemd is not just an init, and, as an init, it takes an architectural approach that is rather disruptive.

Disrupting the fluff end of a market is one thing, but this is not a superficial change like the ipod was in the consumer market. This goes deep to the core of the community of Linux users.

Arguments about whether the architectural changes will turn out to be justified in the end aside, the correct thing for any distribution with a broad user base should have been to make an internal fork, similar to the fork that is kfreebsd in the debian community.

Just dumping it into testing to be processed into the mainline was irresponsible behavior on the part of Red Hat management.

I know that in Fedora they have a policy of not doing forks like kfreebsd, but this was (and will continue to be) disruptive. So disruptive that, if they weren't willing to change policy and set up the separate test community infrastructure, they should have simply refused. They could have told Poettering and his friends, "No. We are not going to sponsor your shiny new vision of an OS, nor your plan to push a shim on top of Linux so you can slide Linux out and slip your re-implementation of VMS or Multics underneath."

You know, that's really not a bad idea, developing a way to get other OSses from a bit outside the Unix traditions underneath the userland applications that have sprung up around Linux. But proper engineering methods should be used in the process.

I personally think the burden should have been on the shoulders of the freedesktop.org group to set up their own distribution. And they should have accepted that burden and not been so anxious to obtain involuntary testers. And they should have been willing to listen to constructive criticism about the design of their software, even if it hurt a bit.

That was the sane way, and the friendly way. Lots of people have set up their own private spins of Linux. It's not that hard, just takes a weekend or two. There's even the Linux-from-Scratch group that will walk beginners through the steps, although we should assume Lennart Poettering, Kay Sievers, and their friends (Did they really call themselves a cabal or were they just being sarcastic?) would not need to be walked through it.

And this is really the core of the argument:

If Red Hat had been willing to do this up-front and set up a parallel distribution (maybe call it Fedora-d) where the engineering questions could be worked out and the shim they are calling an init could have been re-factored more freely when the inevitable design errors were discovered, there would have been grumbling and even a few flame wars. But there would have been nothing like the push-back we have now.

And debian would have been more at liberty to set up a debian-d similar to the way kfreebsd is set up.

And the engineering problems could have been solved with engineering solutions, not with politics.

So, why should I even want to test systemd, even though someone is attempting to push me onto that train?

If I just boot Debian Jessie, I would be testing systemd. Sure.

But I don't really know if I can boot it.

Available hardware? I have one notebook that I'm using for experimenting, an old thinkpad, 256MB total RAM, 32 bit processor, 20GB HD. It runs openbsd (XFCE) okay, although I'm still working out how to get one of the available IMEs to work. A five-year-old vine linux install was a little heavy, but it did work. It is is sitting on the borderline of the level recommended for Debian's current stable OS, Wheezy.

Is it going to be worth wasting the time to see if Jessie runs at all on that? Maybe, but I really don't want to wipe openbsd off of it to do so. I've got things I need to do with that.

Well, sure, it would be pushing systemd beyond certain limits, into functional regions where some of the bugs I expect will definitely show up, but would my bug reports get anything more than a "fix by upgrading hardware" response? Not from what I've seen so far.

One other option, I could load a stripped-down jessie on a 4G SD card and see how it runs on the old netbook with the broken screen, an almost reasonable processor, and 1G of RAM. But, again, wouldn't bug reports tend to get a "fix hardware" response?

It has been asserted time, and time again, on the debian list, that, if I am not finding bugs and reporting them, I'm at fault for the bugs that don't get fixed before the release.


If I add up the time it has taken for me to try to "comment" intelligently, and the time it will most likely continue to take, it would in fact be easier and take less time to just borrow the money to get a new netbook and start digging out the more serious flaws in systemd in my spare time, reporting them to the systemd community, and posting them elsewhere where they will be seen when the systemd community is too arrogant to deal with them (as they have been known to be in the past, see the systemd mailing list).

But
why, exactly, is it supposed to be my responsibility to contribute, when I fundamentally disagree with the direction being taken?

There are some who say that, if systemd is as bad as I and others are guessing, the defects will be made obvious through testing in as many configurations as possible. And if the design itself is fatally flawed, fixing the bugs that are found should not be trivial.

(Many of the bugs so far have not been trivial. No surprise there.)

But, remember, that's what many of us said or thought about MS-DOS, and then about MS-Windows. That is precisely the attitude that allowed Microsoft to get its de-facto monopoly.

I am not saying testing is unnecessary to prove that systemd is fatally flawed, what I'm saying is, if you are not willing to look at and deal with the flaws, testing will not help.

Okay, for those who think you are not technically inclined, who have gotten to this point anyway, how do you learn how to find the flaws?

Learn how to program. 

Don't learn from Microsoft. They'll just teach you how to line up orders that you give to machines and people, as if giving orders and getting your way were all there is to programming.

(One of these days I'll get my Programming Is Fun sites up -- at present, on sourceforge.jp, and blogspot -- but right now there isn't much there.)

One of the primary things anyone should try to understand before trying to become involved with programming on a professional basis is that there are classes of problems for which programmed solutions are not appropriate, for both technical and ethical reasons, if not for reasons involving how we define ourselves as humans.