Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gbrown_
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
96 ms
·
961.
▲
OpenBSD changes of note 2
(tedunangst.com)
2 points
by
gbrown_
10y ago
|
0 comments
962.
▲
by
gbrown_
10y ago
> When we wrote go-audit, there were few, (if any?), distros that had eBPF kernel > support. Now Ubuntu 16.04 has support, as do many others, and that is great! This! I'm rather tired of people preaching about eBPF when in realit
963.
▲
by
gbrown_
10y ago
Whoops! I only skimmed the comments, sorry my bad.
964.
▲
by
gbrown_
10y ago
2016 keeps on delivering.
965.
▲
by
gbrown_
10y ago
You may be interested in the Linux kernel docs[0]. We use it at work to better identify faults with devices hanging off he PCIe bus, namely GPUs and interconnects. [0] https://www.kernel.org/doc/Documentation/PCI&#
966.
▲
by
gbrown_
10y ago
That will make a good weekend read thanks! Others may be interested in Data Structures for Text Sequences by Charles Crowley[0] which describes Piece Tables. This is the basis for the Vis editor[1]. [0] https://www.cs.unm.edu/
967.
▲
by
gbrown_
10y ago
Nice use of -1 there.
968.
▲
by
gbrown_
10y ago
> it was created as a direct response to Heartbleed The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes. https://youtu.be/GnBbhXBDmwU?t=308
969.
▲
by
gbrown_
10y ago
I've only skimmed this but there seems to be a focus on customizing and plugins from the get go. I think it's worth getting to know Vim "as is" before doing such things. Indeed there certainly some things that aren'
970.
▲
by
gbrown_
10y ago
LibreSSL aims to be a mostly API compatible replacement for OpenSSL, BoringSSL does not. Literally the first text on the BoringSSL web page. BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. Althoug
971.
▲
by
gbrown_
10y ago
Dupe of https://news.ycombinator.com/item?id=12691491
972.
▲
Alpine Edge has switched to libressl
(lists.alpinelinux.org)
236 points
by
gbrown_
10y ago
|
81 comments
973.
▲
by
gbrown_
10y ago
I remap { and } so I they land on the first and last lines of a block of text between blank lines, rather than the blank lines themselves. I find this is usually what I want then I just move/ take action in a more targeted fashion with
974.
▲
by
gbrown_
10y ago
Not sure why this appears to be been down voted. Git's command-line interface IS terrible. Certainly not unusable as most of interact with it every day. A somewhat satirical example of this is Steve Losh's Git Koans. http:/&
975.
▲
by
gbrown_
10y ago
The trouble with this isn't the lack of available options (indeed one may argue there are too many). But rather having everyone agree on something with a common API. Also has anything else seen heavy prolonged production usage?
976.
▲
by
gbrown_
10y ago
I'm surprised at the number of daemons in OpenBSD's base that were calling fork() and not then calling exec(). It seems they're now all adopting this which is good.
977.
▲
by
gbrown_
10y ago
> a better approach would be for everyone to try to move to what's in BoringSSL Google don't recommend you do this. https://boringssl.googlesource.com/boringssl/ BoringSSL is a fork of OpenSSL that is
978.
▲
by
gbrown_
10y ago
> Question: on LibreSSL systems, is the binary still named openssl? Yes.
979.
▲
Cross Arch Shellcode Compiler
(github.com)
1 points
by
gbrown_
10y ago
|
0 comments
980.
▲
by
gbrown_
10y ago
This option only got added in recently. I think it would have been better if this were pointed out in the post. But trying not to sound too snide there's something to be said for checking the man page before copying config off the inte
981.
▲
by
gbrown_
10y ago
Unfortunately it will be years before myself and many others get to use BPF on our production systems as we have to run an "enterprise" distribution like RHEL or god forbid SLES. But yes it certainly is good to see steps being mad
982.
▲
by
gbrown_
10y ago
> Does anyone have any inside knowledge of when, if ever, DTrace might become a standard/official part of Linux? Never. Due to dtrace being licensed under the CDDL it will never be mainlined into the upstream kernel. I would be keen
983.
▲
by
gbrown_
10y ago
Just wanted to share this video given at ANL recently which goes into the cost of communication in such methods. It has a HPC focus but the presentation is quite digestible. https://www.youtube.com/watch?v=TUViqCd9EKk
984.
▲
by
gbrown_
10y ago
On the subject of papers, for those who have not read them Jeff Bonwick's work on the Solaris slab allocator is well worth reading. https://www.usenix.org/legacy/publications/library/proceedin... https:
985.
▲
by
gbrown_
10y ago
Anyone have details on the cache design for this? 2048 bits is much larger than most cache lines in chips today.
986.
▲
by
gbrown_
10y ago
There's a click bait title if ever I saw one. A single benchmark is run without numbers and the AMD part only completes just ahead of the Intel part (which is down clocked by 200Mhz). Not got anything against AMD, just the title. Reall
987.
▲
by
gbrown_
10y ago
I've not dug into this enough yet but all prior generations of Nvidia GPUs have had caveats when adding steps to unify main memory. It certainly isn't "one address space" as far as the OS is concerned, perhaps Nvidia is
988.
▲
by
gbrown_
10y ago
Do you still need to use vector instructions on KNL to get top performance? Yes, but this is also the case for regular Xeons. If so then forgot about "familiarity" when rewriting. When I say "familiarity"
989.
▲
by
gbrown_
10y ago
I agree with all of your points but I think KNL will be a turning point. Traditional multi core CPUs simply aren't an option to advance in the HPC space any more. Per generation there's not enough of a performance improvement to m
990.
▲
by
gbrown_
10y ago
KNC effectively runs BusyBox with tweaks.
More ›