When drives are never replaced, yes. In the case where the chassis lasts longer than the drives (which I'd imagine is often), extra cost in drives adds up.
51 karma · joined May 1, 2013
Accepting compiled stuff in the form of a kernel module requires root privileges and requires that the kernel essentially have complete trust in the code being loaded.
Loading eBPF eliminates the need to trust the process/user doing the loading to that level.
Normal C caveats do apply here though: alloca is POSIX, not C (but is widely implemented outside of POSIX systems). VLAs are an optional standard feature. Neither is required to actually use the stack for storage.
Not sure if there are any platforms supported by curl which would prevent it's use of VLAs or alloca.
1. no use of a kernel supplied page, determines skew/etc itself in userspace 2. stores information on a per-cpu level, and tries to execute cpuid on the same cpu as rdtsc.
I'm presuming you're talking about #2 (and #1 is just due to the linked item being a library without kernel integrations)? Perhaps with some more kernel support so that the actual cpu rdtsc ran on can be reliably determined?
This still doesn't clarify the part about "shared page in which the time is updated" and is read from. This statement appears to imply TSC is not (necessarily) used (otherwise I'd categorize it under "uses values from memory page to fixup TSC", like Illumos' current implimentation). I'm still not sure how that can be done reasonably.
Is there just a 1 micro second timer running whenever a user task is being executed that is bumping the value? Wouldn't that be quite a bit of overhead? Or some HW trick? I mean, you could generate a fault on every read, and have the kernel populate the current data, but that seems just as bad as a syscall.
- comm_page (usr/src/uts/i86pc/ml/comm_page.s) is literally a page in kernel memory with specific variables that is mapped (usr/src/uts/intel/ia32/os/comm_page_util.c) as user|read-only (to be passed to userspace, kernel mapping is normal data, AFAICT)
- the mapped comm_page is inserted into the aux vector at AT_SUN_COMMPAGE (usr/src/uts/common/exec/elf/elf.c)
- libc scans auxv for this entry, and stashes the pointer it containts (usr/src/lib/libc/port/threads/thr.c)
- When clock_gettime is called, it looks at the values in the COMMPAGE (structure is in usr/src/uts/i86pc/sys/comm_page.h, probing in usr/src/lib/commpage/common/cp_main.c) to determine if TSC can be used.
- If TSC is usable, libc uses the information there (a bunch of values) to use tsc to read time (monotonic or realtime)
Variables within comm_page are treated like normal variables and used/updated within the kernel's internal timekeeping.
Essentially, rather than having the kernel provide an entry point & have the kernel know what the (in the linux case) internal data structures look like, here libc provides the code and reads the exported data structure from the kernel.
So it isn't reading the time from this memory page, it's using TSC. In the case of CLOCK_REALTIME, corrections that are applied to TSC are read from this memory page (comm_page).
It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon.
When I was using mercurial, I ended up using the mq extension [1] to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
> Although limiting liability online was intended to protect sites hosting digital content, it carried over to service platforms
At that point, the requester could cache that output, should they want to.
The limit exists because there is a ~1KiB kernel memory overhead per watch (though there should really be a way for them to take part in normal memory accounting per-process).
If one wants to watch a directory tree, one needs an inotify watch handle per subdirectory in that tree. On large trees (or if more than 1 process is using inotify), that number of watches can be exceeded.
As lots of folks are looking for recursive watches, they aren't happy with needing to allocate & manage a bunch of handles when they see what they want as a single item.
That said, I'm not sure the way the kernel thinks about fs notifications internally would allow a single handle recursive watch at the moment.
In any case, the amount of info one can obtain by using fuse (or any fs like nfs or 9p) to intercept filesystem accesses is a bit larger. At the very least, one can (in most cases) directly observe the ranges of the file that were modified (though that's not quite so important for tup, afaik). There also aren't any queue overruns (which can happen in inotify) because one will just slow the filesystem operations down instead (whether this is desirable or not depends on the application).
> "some way for tup to manage discovering the files to build"
Well, no. It's not a "convention" build tool like rust's `cargo` where you just place things in the default locations and it figures it out.
You can use the `run ./script args` mechanism in tup to run your own script that emits tup rules, though.
The manual has details: http://gittup.org/tup/manual.html
I agree, it would be useful to evaluate it here as it provides a bunch of the features the other "build tools" provide.
Article doesn't note the property of being able to depend upon the entire command that generates an output (ie: re-generate when compiler flags change). This is something that makes doing reliable builds much easier (when present). It's notably very hard to do in make (and even then is very inefficient).
Also, on "download" the author seems to presume that one takes the naive approach in each tool. In most cases, if one spends a bunch of time on it the downloads can be done fairly efficiently (especially in make, without even much work there). Most of these build systems are fully programmable, so the rating should probably focus more on the level of difficulty to do well (with some requirements specifying what "well" is)
I'd say:
> don't post anything publicly if you want only [warm fuzzy feelings]"
I believe gentoo's emerge also has support (though I'm not as sure here as I typically have the downloads happen in the background while building).
The overall goal here is to more effectively utilize the available bandwidth on the client side even when there are limitations a given server.
It's great that we can customize how to download 1 package at a time. But there is room for improvement.
I've been searching through old HN stories about Eich, but can't seem to find any where the comments generally supported firing him due to supporting Prop 8 (banning gay marriage).
Is there a particular thread you had in mind? Or are you stating the overreaction was being angry that he might have been fired over that support?
Also note that by singling out Google Analytics, it's possible that the data might be collected and used by other Google tools, just not GA. Depends on how much mental gymnastics they are willing to do.
Of course, the best thing would be someone just looking at the actual javascript and seeing what it does.
Not that I really expect that to happen anytime soon, I believe others have been asking for the above for quite some time.
Does go not support being cross compiled/cross compiling?
This could certainly be done via a custom PAM module. Of course, we should also consider that admins will often have physical access to the systems. I can't think up a purely technical solution to enforce the 2 man rule.
This method of getting a warrant completely subverts reasons a warrant is required. It turns a warrant into a sham.
I'm afraid I'm not familiar with what scale Yahoo operates on, but wouldn't it be more beneficial for them to merge Astrid into whatever their plans are rather than drop them and alienate people who were already users?
Or was it just seen as a potential resource hole (with the value of the users seen as negative)?
Can anyone shed some light on what Astrid's business model was?