Agreed. When it comes to naming things, I really like the way Russ Cox puts it: https://research.swtch.com/names
1,241 karma · joined October 24, 2012
A good way to prevent this is to have a buffer abstraction, where the size is a property of the type, e.g.,
typedef struct {
size_t bytes_used;
size_t capacity;
void *data;
} buf_t;
int buf_init(buf_t *buf);
void buf_cleanup(buf_t *buf);
void buf_copy(buf_t *dst, buf_t *src);
/* ... */
Protobufs and similar serialization protocols are great for complex data. It is worth pointing out that we've had ASN.1 for a while and it's pretty fast too, at least for limited subsets of OIDs/types, in certain encodings, though XER or JER would probably not compete with BER.
HTTP/2 is a complex protocol designed to fix problems with the way people build websites today. A lot of its features does not make sense/is not needed for simple message passing.
e.g., some HTTP/2 implementations will probably see HPACK DoS bugs/vulns because HPACK is stateful, whereas if HTTP/2 wouldn't have HPACK that problem would not have existed, but the reason why HTTP/2 has HPACK is because people bloat headers with tons of stuff.
IRC works and works well for its use case. Apart from newline-delimited strings - netstrings and TLV are other examples of formats that can build great, simple and introspectable/open formats.
I'd venture a guess and say that an RFC1459 PRIVMSG message parses faster than a protobuf message carrying the same information - due to parsing an RFC1459 PRIVMSG message is so simple. Of course, if you want arbitrarily sized messages, or messages with an arbitrary number of nested messages inside it you need more complexity.
Or newer. e.g., I use gitk daily at work.
On systems that implement them, Tcl can use select, epoll, kqueue for its event notification implementation, as well as pthread_cond_broadcast for threads (if built with thread support).
take a look at:
generic/tclNotify.c - https://core.tcl.tk/tcl/artifact/8804164706c8f2cb
unix/tclEpollNotfy.c - https://core.tcl.tk/tcl/artifact/892b68fa5a7c4c87
Callback passing and coroutines are well known techniques that's been around for a while. Generators are just coroutines that yield to their parent. I remember using these concepts in C and Tcl ~15 years ago[1] and they were well known then. According to wikipedia (citing Knuth), the term coroutine was coined in the late 50's by Conway.
Callback passing and coroutines suits some problems well. Sure there are situations where they do not fit and if people use a hammer for all of their problems they will create new ones. I wouldn't call it a fad, though the techniques may be a bit hyped up in some circles.
[1] I don't remember when Tcl got the coroutine package, that may have been later
x = function(x) return x*x end
Not that it really matters though, bridges still get built.
"A Scalable Concurrent malloc(3) Implementation for FreeBSD", Jason Evans, April 16, 2006
Felt very sick and disorientated afterwards. Had swallowed what I at the time perceived to be a lot of blood, which I vomited for one or two days. Couldn't eat, tasted the ice cream twice.
Pretty sure my nose could've been pulled into place without general anesthesia, but maybe that would've been scary too.
For comparison, Sweden is about the size of California, with roughly one forth of its population.
> In the US, on average if you want to see a better form of political discourse, you have to move toward more local politics (whether state, county, city, town).
In my experience, local politics tends to be... More entertaining. Maybe because it's a lower barrier for entry.
> Sweden = local politics. It's a small nation. 25% of their population lives in just four cities.
The majority of its population lives outside of the largest four cities. There's a lot of difference between those four cities as well.
Company X, a content publisher, has a wordpress site with a bunch of plugins. They hear that the security record of such a setup is less than ideal. They buy a WAF solution to protect them.
Company Y, also a content publisher in the same space, realizes that they don't need dynamically generated content. They don't need tons of JS. They start publishing static content and what little dynamic functionality they have is well-compartmentalized, with interactions to the outside world carefully audited.
Company Y could also get a WAF, but why? It increases the attack surface, Company Y probably don't have the time/expertise to audit it, it is not clear what benefits it will have.
Looks like they had their own character set
fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or similar). fork+execve+process-runtime-initialization is much slower.
On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-child+wait takes:
$ /usr/bin/time ./forkfest
2,49 real 0,38 user 2,19 sys
$ /usr/bin/time ./forkfest2
10,99 real 3,10 user 7,94 sys
"The total estimated program cost is $3.2 billion"
The reason for both of these deals seems to be somewhat correlated to Iskander units in Kaliningrad.
Let's say there's a service failure and I want to know what the service has done prior to the failure. I wouldn't want a classifier to filter the logs in that case, so that use case is out of the picture. What other use cases than filtering are there for this? Maybe as a way to provide feedback to developers to fix the log messages, as in "this thing that we log all the time can be determined to never affect the process of trouble-shooting our services, and the classifier thinks it's noise, so we'll remove it".
$ ldd chrome | wc -l
124
Current window size is 1280x800. Assuming the render buffer is ARGB32 and assuming one render buffer (which is probably an incorrect assumption) that should be ~40MB. The GPU memory is listed as a separate entry in that view, but I don't know if that is also included in the "private memory" listing.
Going turn off javascript and restart and see what it says then.
EDIT: 164 856 kB w/o JS. So no change (relatively).
Can't find separate listings for libc in FreeBSD, OpenBSD but the list is smaller than glibc if you check e.g., VuXML or https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...
Looks like glibc is the worst sinner here.