switch to room list switch to menu My folders
Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last
[#] Mon Jul 28 2014 14:12:52 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hm... actually, modifying the code to handle what was missing in the native zlib might have cost me less effort than having to install an updated zlib for these OSes. I shall never have to deal with updating the zlib (forgetting to do so, pulling into the rpm I need to build, or whatever). Theoretically, once I build this (particularly if I link to my libs statically), I am free to simply copy the binary where I want it, and it should work.

We'll see as I get further into this.

[#] Mon Jul 28 2014 15:21:18 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Could be you need gnu tar, and you can download binaries of that from

the usual suspect Sun ports site - used to be was the

best place to go, and it's still around, though I don't know if it's
still your best bet. However, you should definitely save yourself some

/opt/sfw is on pretty much every Sun system over here ... and their numbers are dwindling as people figure out it's a lot easier to just use Linux.

[#] Mon Jul 28 2014 15:41:41 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh, I got around the 'tar' problem, incidentally, by compiling it from GNU's sources rather than using the packaging system.

Because, at the end of the day, you can compile almost anything and make it work with enough willpower.

[#] Mon Jul 28 2014 16:13:20 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

last time I cared was the most reliable source for fresh solaris ports.

[#] Mon Jul 28 2014 16:33:48 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It isn't altering the OS if you want to quibble, but it's forcing me

to have to change something I suspect is kind of primal to the
operating system such that it isn't what it originally was anymore,
which I fear could have a rippling effect on the rest of the system.

Ok, if you install a library in /usr/local it goes onto the compiler include path by default, which may not be what you want. So. Install it in, say, /opt/gnu, along with the rest of the toolchain you're installing, and you won't have that problem.

This is the usually recommended way to build a stack of dependencies that may be differently versioned from what's included in the base OS.

[#] Mon Jul 28 2014 16:35:34 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(if it isn't completely clear, doing things as described above will link zlib with the compiler toolchain you're building, but not with binaries generated by that toolchain - by default.)

[#] Tue Jul 29 2014 08:18:48 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That'd work.

If I did that, of course, I'd have to ensure that I install the library somewhere on the OS. It's yet another dependency I would need to track.

If I do it my way, I don't have that dependency, and setup is simplified.

[#] Tue Jul 29 2014 08:34:44 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Perhaps I should point out that the two functions I needed out of the updated zlib was 1. compressBound, which simply calculates an estimate of how much space is needed for the compression, and 2. ceil, which is used by compressBound for its calculation, is normally included in 'math', but for some peculiar reason I can't link that library into the compiler.

Neither of these functions are revolutionary or terribly difficult to implement.
If I needed 10 functions, some of which involved some relatively intricate programming that would be unwise of me to attempt, yeah, I would suffer the setup dependency. But for the price of creating two very simple functions, avoiding a setup dependency seems like the better way to go.

At least, that's my reasoning.

[#] Tue Jul 29 2014 09:18:46 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

since docker (LXC) seems to be hot tech, see this one:

FIG seems to be a really nice tool:

[#] Tue Jul 29 2014 10:24:42 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That looks rather useful... isolated dev environments in a flash.

[#] Tue Jul 29 2014 10:29:20 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Fucking hell... trying to read anything about Docker is like reading a web site full of nothing but buzzwords.

I feel like I'm listening to Weird Al's "Mission Statement" tune.

I assume eventually I'll read something that actually has some real meat to it, but honestly, I'm incredibly turned off by all this buzzword shit.

[#] Tue Jul 29 2014 11:18:56 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

thats because of its 95% LXC, some added guts, and LOTS of marketing.

[#] Tue Jul 29 2014 11:25:34 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Gah... fucking marketing...

The usual enmity between engineering and marketing continues.

[#] Tue Jul 29 2014 11:28:51 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Another awful thing... Valhalla Linux doesn't have a concept of a steady clock within it.

The only clocks I can find for this is a clock that matches the 'real time', and is subject to the usual crap when you adjust the time, and process/thread CPU clocks, which are not exactly steady. There is no way that I can see right now that you can get a kind of clock that simply iterates over a steady rate of time, monotonically.

Did people writing for Valhalla wind up with obscure and weird problems when people changed their time?

[#] Tue Jul 29 2014 11:29:19 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(Sorry, I wrote 'Valhalla Linux', which is stupid... RedHat Valhalla is what I mean).

[#] Tue Jul 29 2014 12:48:57 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

you're supposed to run ntpclient in cron or such.

VM-clocs are even less predictable then usual system clocks.

Ticks are supposed to be somewhat predictable..

[#] Tue Jul 29 2014 12:51:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

what you're looking for might be /proc/loadavg, which is used by the "uptime" command...

[#] Tue Jul 29 2014 12:52:33 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

/proc/uptime ooks like the the same thing, higher resolution?

[#] Tue Jul 29 2014 13:07:05 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(I got this by running "strace" on the /usr/bin/uptime. the program queries both /proc/loadavg and /proc/uptime (oops) so the latter is the one that's relevant.

these have been around for a while, so they should work on rh6.2 even.

[#] Tue Jul 29 2014 13:15:37 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Thanks for the information!

Here's something else to add to it:

If I'm reading this correctly, back then, people tried to ensure that time marched forward by relying upon the NTP client to adjust the system clock in monotonic ways. So, you'd never change the system clock yourself... you would let NTP do it for you, and it would always adjust the clock in a fashion that is monotonic in nature.

Obviously, folks must have figured out how bad this idea was, as we now have CLOCK_MONOTONIC available for clocks in current kernels, but I guess we had some relatively naive notions about time back then.

Sooo, at least philosophically, I should be able to use the realtime clock as if it were the steady clock, and avoid adjusting the time/date on the machine, just as I guess they intended back in the day.

I have to figure out how to coerce my code to do this... it *really* wants CLOCK_MONOTONIC or the like. I tried #defining it to CLOCK_REALTIME and now I have a linking error. But I'm sure I can get past that with a little evil.

Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last