Posted on Leave a comment

Linus Entertains

Date:	Wed, 6 Sep 2000 12:52:29 -0700 (PDT)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	Tigran Aivazian <tigran@veritas.com>
Subject: Re: Availability of kdb



On Wed, 6 Sep 2000, Tigran Aivazian wrote:
> 
> very nice monologue, thanks. It would be great to know Linus' opinion. I
> mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> is a living being and not some set of rules written in stone so perhaps
> current stability/highquality of kdb suggests to Linus that it may be
> (just maybe) acceptable into official tree?

I don't like debuggers. Never have, probably never will. I use gdb all the
time, but I tend to use it not as a debugger, but as a disassembler on
steroids that you can program.

None of the arguments for a kernel debugger has touched me in the least.
And trust me, over the years I've heard quite a lot of them. In the end,
they tend to boil down to basically:

 - it would be so much easier to do development, and we'd be able to add
   new things faster.

And quite frankly, I don't care. I don't think kernel development should
be "easy". I do not condone single-stepping through code to find the bug.
I do not think that extra visibility into the system is necessarily a good
thing.

Apparently, if you follow the arguments, not having a kernel debugger
leads to various maladies:
 - you crash when something goes wrong, and you fsck and it takes forever
   and you get frustrated.
 - people have given up on Linux kernel programming because it's too hard
   and too time-consuming
 - it takes longer to create new features.

And nobody has explained to me why these are _bad_ things.

To me, it's not a bug, it's a feature. Not only is it documented, but it's
_good_, so it obviously cannot be a bug.

"Takes longer to create new features" - this one in particular is not a
very strong argument for having a debugger. It's not as if lack of
features or new code would be a problem for Linux, or, in fact, for the
software industry as a whole. Quite the reverse. My biggest job is to say
"no" to new features, not trying to find them.

Oh. And sure, when things crash and you fsck and you didn't even get a
clue about what went wrong, you get frustrated. Tough. There are two kinds
of reactions to that: you start being careful, or you start whining about
a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being
careful early rather than late. That sounds callous, and by God, it _is_
callous. But it's not the kind of "if you can't stand the heat, get out
the the kitchen" kind of remark that some people take it for. No, it's
something much more deeper: I'd rather not work with people who aren't
careful. It's darwinism in software development.

It's a cold, callous argument that says that there are two kinds of
people, and I'd rather not work with the second kind. Live with it.

I'm a bastard. I have absolutely no clue why people can ever think
otherwise. Yet they do. People think I'm a nice guy, and the fact is that
I'm a scheming, conniving bastard who doesn't care for any hurt feelings
or lost hours of work if it just results in what I consider to be a better
system.

And I'm not just saying that. I'm really not a very nice person. I can say
"I don't care" with a straight face, and really mean it.

I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_.

It's partly "source vs binary", but it's more than that. It's not that you
have to look at the sources (of course you have to - and any good debugger
will make that _easy_). It's that you have to look at the level _above_
sources. At the meaning of things. Without a debugger, you basically have
to go the next step: understand what the program does. Not just that
particular line.

And quite frankly, for most of the real problems (as opposed to the stupid
bugs - of which there are many, as the latest crap with "truncate()" has
shown us) a debugger doesn't much help. And the real problems are what I
worry about. The rest is just details. It will get fixed eventually. 

I do realize that others disagree. And I'm not your Mom. You can use a
kernel debugger if you want to, and I won't give you the cold shoulder
because you have "sullied" yourself. But I'm not going to help you use
one, and I wuld frankly prefer people not to use kernel debuggers that
much. So I don't make it part of the standard distribution, and if the
existing debuggers aren't very well known I won't shed a tear over it.

Because I'm a bastard, and proud of it!

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Posted on Leave a comment

kscript – Having fun with Kotlin scripting

https://www.kotlinresources.com/library/kscript/

Enhanced scripting support for Kotlin on *nix-based systems.

Kotlin has some built-in support for scripting already but it is not yet feature-rich enough to be a viable alternative in the shell.

In particular this wrapper around kotlinc adds

  • Compiled script caching (using md5 checksums)
  • Dependency declarations using gradle-style resource locators and automatic dependency resolution with jcabi-aether
  • More options to provide scripts including interpreter mode, reading from stdin, local files or URLs
  • Embedded configuration for Kotlin runtime options
  • Support library to ease the writing of Kotlin scriptlets
  • Deploy scripts as stand-alone binaries

Taken all these features together, kscript provides an easy-to-use, very flexible, and almost zero-overhead solution to write self-contained mini-applications with Kotlin.

Posted on Leave a comment

Windows 10 Ubuntu App Shell

.bashrc

su : root -> .bashrc

.bash_profile -> ssh

.profile

When Bash is invoked as an interactive login shell, or as a 
 non-interactive shell with the --login option, it first reads 
 and executes commands from the file /etc/profile, if that file
 exists. After reading that file, it looks for ~/.bash_profile, 
 ~/.bash_login, and ~/.profile, in that order, and reads and executes
 commands from the first one that exists and is readable. The 
 --noprofile option may be used when the shell is started to inhibit
 this behavior.

.bashrc is a shell script that Bash runs whenever it is started interactively. It initializes an interactive shell session. You can put any command in that file that you could type at the command prompt.

There could be some messy implementation variations depending on the flavour of Unix, Ubuntu, macOS, etc.

Posted on Leave a comment

Dynamics Arises From Statics

When Equilibrium Is Not Established In Time.

The propagation takes time in nature due to the limited speed of light. The speed of light is thought to be the maximum speed limit that information can propagate.

Random events occur at all times randomly and equilibrium cannot be established instantly.

Enter the non-equilibrium non-linear dynamics

Uncertainty in our space-time causes random events. This is called uncertainty principle. The ultimate cause of all the mess in the Universe.

Living things lie. Non-living things also lie. Even our space and time lie. We All Lie.

Dynamics is here to handle all things that lie.

Classical Mechanics, Electrodynamics and Quantum Electrodynamics (QED) are well known a few good examples of dynamics.

There are countless not well-known dynamics. Some are discovered, and the rest are yet to be discovered.

Posted on Leave a comment

Web Workers and the DOM

Web workers do not have access to the following JavaScript objects:

  • The window object
  • The document object
  • The parent object

main.js runs in the main UI thread

var worker = new Worker("worker.js")
woker.onmessage = function(event) {
    document.getElementById("result").innerHTML = event.data
}
// Post message to the worker
worker.postMessage({"cmd": "start", "msg": "Hello"}) 

worker.js runs in a separate thread

self.onmessage = function(event) {
    var data = event.data
    self.postMessage(data.cmd + " " + data.msg)
}

Note: There are two ways to stop a worker: by calling worker.terminate() from the main UI thread or by calling self.close() inside of the worker thread.

Use Transferable objects to efficiently pass binary data between main and worker thread without copying the data. The usual FileBlobArrayBuffer, and JSON objects will be copied between main thread and worker thread, making them more resource expensive.

Posted on Leave a comment

AudioBuffer Timing Precision

It can anywhere between 100ms and 20 micro seconds.

It all depends on the browser.

AudioContext.currentTime returns a double representing an ever-increasing hardware timestamp in seconds with a certain precision that can be used for scheduling audio playback, visualizing timelines, etc.

AudioBuffer can be started at the particular time.

AudioBufferSourceNode.start([when][, offset][, duration])

For one example, a seamless two-buffer playback.

AudioBuffer0.start()
AudioBuffer1.start(AudioBuffer0.buffer.duration)

AudioBuffer1 will start when AudioBuffer0 is done. Hopfully, this will play continuously without hick-up between buffer0 to buffer1 transition. And when AudioBuffer0.onended event fires, queue another AudioBuffer0 with the start time set to the end time of AudioBuffer1. At AudioBuffer1.onended event, queue another AudioBuffer1 with start time of the end of AudioBuffer0. By switching between these two buffers, it should play smoothly and continuously as if it is one longer buffer.

Not sure if this really will work as expected. To be determined later by actually coding to this spec.

The real test result: there are audible hick-ups. It does not work. :-0

createScriptProcessor is last hope.