Slashdot Mirror

Why would something you describe as an illustration be relevant, or something I would look at?

All you did is wave your hands and say "yer rong," and then do some scribbles? What?

How the fuck does "Unix" even know when somebody will decide to add the shit? Obviously, what you're saying may or may not apply to some sort of *nix system that exists, (not that you established or claimed even that much!) but it clearly isn't something universal.

Instead of drawing illustrations, here is a link that explains the details:
http://www.madore.org/~david/c...
Note this key part:

If the year is =1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
        (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
        ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

—The Open Group, Single Unix Specification, Base definitions (4: General concepts)

This is why others, who are really obsessed with having the computers know about leap seconds, say that unix support for them is broken. Often it seems that the people promoting it simply think that adding leap seconds is the only correct answer, and that prevents them from even understanding the technical issues involved. It isn't clear that there is even a use case for having the computers know about it, because counting actually elapsed seconds is a major import thing that you do in software, and fixing the wall clocks that humans use to better match the rotation of heavenly bodies is a rare use case that is different than the things that computers are already using the system clock for. So it makes more sense to use another system to account for it, like a network time daemon that is already necessary to compensate for drift.

"So why assume 0-59?"

Because, POSIX.

The committee which created POSIX (has any "design by committee" ever gotten things right?) decided to create an impossible situation - they both define a timescale of seconds in an epoch, AND define a day to be exclusively 86400 seconds. The only way that's possible is if a POSIX system doesn't claim to maintain UTC. Most/all do.

Here's a good explanation, with the gory details.

N.B. Leap seconds existed before POSIX, so they had the opportunity to get it right. They didn't. Leap seconds don't cause problems. POSIX does.

One of the issues if that if you need a high-resolution measurement of the real time that has passed between one event and another, it simply isn't available under POSIX systems. For scientific purposes, that sucks.

http://www.madore.org/~david/c...

Because in terms of math, cutting edge theory, and elegance, Haskell just blows everything I’ve seen out of the water.

Try #haskell, to get you started on the theory. But don’t be surprised if it feels like another planet, when they make jokes about The One True Monoid, and Unlambda. ;)
(The are also much friendlier with mathematical questions, than the #math channel, where every free thought or idea is punished with anti-troll trolling, aggression, hate and the banhammer, and socially acting even remotely like a human is taboo. ;)

Encrypting one's entire filesystem ( especially on a laptop ) is a common corporate policy to prevent a stolen laptop from resulting in bad guys getting company data. Having such software installed is common for legitimate reasons.

A promising looking p2p data storage system which meets your requirements is this: http://www.madore.org/~david/misc/freespeech.html. It's based on the fact that the same data can be interpreted in more than one way. 128k of bytes can be interpreted by another 128k of bytes as an MP3 song fragment, or by yet another 128 k of bytes as an illegal list of credit card numbers.

It sounds like you want some form of mandatory access control. The most popular ones are SELinux and AppArmor, but there are other approaches, each one claiming that the others are horrible. There are also considerably simpler setups like cuppabilities, which are written into the app itself, rather than being imposed in a system-wide manner.

I think Dan Bernstein wrote something about how to drop as many privileges as possible from a userspace program, but I'm blanking on where it was, or how useful it is to normal folks.

There's a scheme for p2p that breaks up files into 128 k chunks such that any particular chunk is nothing but random data without the other chunks AND crucially the same chunk may be and likely is part of a movie a word document, a family photo and any number of legitimate files.

The chunks are distributed about the network, and the pointers are hashes of the data. ( I can't see the site right now because of where my computer is sitting so my recollection of the details may be wrong, I can't check. See the above link for the straight dope. ) Anyway, you basically run a webserver locally that does the p2p retrievals when you visit a link of the form http://localhostsomeport/hashcodeofsomedata Then your locally running webserver gets the needed data, pieces it together and serves it to your web browser.

Nobody can know what the chunks are because they appear to be random data, and nobody can say you downloaded ( or are serving ) something bad because the chunks have legit uses. And instead of some stupid song search client you use your web browser to browse the p2p web. Google could index this p2p web if it wanted to.

The only thing that can put the data chunks into the form of a particular ( possibly naughty ) file is the url pointing to it. And those urls can be in ( for instance ) index.html files on the same p2p web. If you post a p2p link to a copyrighted file on the 'regular web' then sure you might be in trouble, but if you post a link to a p2p page without copyrighted content but which contains links to other p2p pages, and some of those pages then contain links to copyrighted content, then I don't see how you could be in trouble since it's unreasonable for you to be expected to examine the page you link to, all the pages that page links to, and all the pages those pages link to ( i.e. crawl the whole web and examine all the pages ) before posting a link.

Really, I think Madore's p2p scheme is the best thing in p2p today, solving all p2p's current problems except one, namely why should I not leach? Still, I think it could put a real cramp in anyone who wants to censor.

I wonder if you could define a database data structure and run a process that stores the index to the p2p web in that distributed database. Then you could publish the search engine code ( or many different search engines, if the database structure were 'open' ) which would query the database for search results. Then you could cut google right the hell out of the picture. All you would need is one good person to run the web crawler process which keeps the database updated. Hell there might even be some way to have the crawling aspect of things distributed, but that's for a future release.

Something like this really ought to take over. I can't see why it hasn't already.

UNLAMBDA is going to have a new Life! I never really liked reusability anyway.

In the unlambda distribution there are some (unnecessary, but convenient) added operators.

Maybe, but Unlambda 2 is more interesting in many evil ways. Abstraction elimination is the lambda calculus in the wrong (for humans) direction, since our monkey brains like functions, procedures and equations that can be described by a relatively simple and easy to remember name.

http://www.madore.org/~david/misc/freespeech.html Was a more useful explanation. If having a pad that 'allows someone to get the mp3' would be illegal, making someone a criminal would be a matter of finding _any_ sufficiently large file this person serves and making a bunch of pads of which a combination makes the mp3.

INTERCAL is a bit like learning FORTRAN - it's a bit long of tooth - maybe try bf, unlambda, whitespace or my personal favorite, java2k. Any base 11 probabilistic programming language is tops in my book.

• Lambda calculus-ish
  • Scheme
  • Haskell
• Combinator/Forth-ish
  • Joy
  • Interesting but not practical: unlamdba iota and jot
• Logic
  • Prolog
  • Mercury - compiled and pure
  • Lygon - prolog like linear logic programming.
• Pi calculus-ish
  • Join calculus
  • Nomadic Pict

I think I want to master logic programming next, though it may be better for me to do some haskell programming first so I have a better foundation. Monads/Arrows give me a headache, but with enough time, I'm sure I could get used to them. s-expressions a-la lisp/scheme are very similar to xml, except better, but logic programming seems more likely to make the hardest parts of internet programming easier.

Unfortuately, I have nowhere near enough time to get proficient in all these languages.

PERL lacking bloat? You've got to be kidding!

If you want minimal, try out UnLambda or Pax. Unlambda is so minimal the functions (except a few built-ins) don't even get names. As a purely functional language, it also lacks variables. Despite this, it's Turing complete, so it can do anything you can do in such bloated messes as C++, PERL or Python. Pax is also Turing complete, and the page referenced above includes complete source code to its implementation, in a total of 175 lines of code (including white space, nice indenting, etc.)

What's truly sad is that even though it was apparently invented with the specific intent of being obfuscated, Pax programs are generally much more readable than most PERL. Oh, and just to address a couple of your other points: Pax doesn't need a library to do pattern matching -- in fact, the language is basically built entirely around pattern equations. The tutorial and reference manual together work out to just over 200 lines of text. Most of that is the USTL reference manual mentioned above.

Much as I hate to, I have to admit that even compared to PERL, programs in UnLambda are somewhat obfuscated -- though once you get used to its syntax, they're not quite as bad as they initially appear (rather the opposite of PERL in that respect).

Pfft. Haskell is for wusses.

Eep. More complete version.