Hexbyte  Hacker News  Computers The future’s so bright, I gotta wear blinders

Hexbyte Hacker News Computers The future’s so bright, I gotta wear blinders

Hexbyte Hacker News Computers

“This is only the beginning,” writes Kevin Kelly in an essay in Wired‘s 25th anniversary issue. “The main event has barely started.” He’s talking about the internet. If his words sound familiar, it’s because “only the beginning” has become Kelly’s stock phrase, the rhetorical device he flourishes, like a magician’s cape, to draw readers’ eyes away from what’s really going on. Back in 2005, in a Wired story called “We Are the Web,” Kelly wrote, “It is only the beginning.” And then, his enthusiasm waxing, he capitalized it: “the Beginning.” He doubled down in his 2016 book The Inevitable: “The internet is still at the beginning of its beginning.” And then: “The Beginning, of course, is just beginning.”

I predict this sentence will appear in the next thing Kelly writes: “The beginning of the Beginning will be beginning shortly.”

This is not the beginning, much less the beginning of the beginning. We’ve been cozying up to computers for a long time, and the contours of the digital era are clear. Computers have been around for the better part of a century, computer networks have been around since the 1950s, personal computers have been in popular use since the late 1970s, online communities have been around at least since 1985 (when the Well launched), and the web has been around for a quarter century. Text messaging on mobile phones started in 1984, the first BlackBerry smartphone was released in 2002, and the iPhone arrived in 2007. The social network MySpace was popular 15 years ago, and Facebook went live in 2004. Last month, Google turned 20. In looking back over the consequences of computer-mediated connectivity since at least the turn of the century, we see differences in degree, not in kind. 

A few years ago, the technology critic Michael Sacasas introduced the term “Borg Complex” to describe the attitude and rhetoric of modern-day utopians who believe that computer technology is an unstoppable force for good and that anyone who resists or even looks critically at the expanding hegemony of the digital is a benighted fool. (The Borg is an alien race in Star Trek that sucks up the minds of other races, telling its victims that “resistance is futile.”) Those afflicted with the complex, Sacasas observed, rely on a a set of largely specious assertions to dismiss concerns about the ill effects of technological progress. The Borgers are quick, for example, to make grandiose claims about the coming benefits of new technologies (remember MOOCs?) while dismissing past cultural achievements with contempt (“I don’t really give a shit if literary novels go away”).

To Sacasas’s list of such obfuscating rhetorical devices, I would add the assertion that we are at “the beginning.” By perpetually refreshing the illusion that progress is just getting under way, gadget worshippers like Kelly are able to wave away the problems that progress is causing. Any ill effect can be explained, and dismissed, as just a temporary bug in the system, which will soon be fixed by our benevolent engineers. (If you look at Mark Zuckerberg’s responses to Facebook’s problems over the years, you’ll find that they are all variations on this theme.) Any attempt to put constraints on technologists and technology companies becomes, in this view, a short-sighted and possibly disastrous obstruction of technology’s march toward a brighter future for everyone — what Kelly is still calling the “long boom.” You ain’t seen nothing yet, so stay out of our way and let us work our magic.

In his books Empire and Communication (1950) and The Bias of Communication (1951), the Canadian historian Harold Innis argued that all communication systems incorporate biases, which shape how people communicate and hence how they think. These biases can, in the long run, exert a profound influence over the organization of society and the course of history. “Bias,” it seems to me, is exactly the right word. The media we use to communicate push us to communicate in certain ways, reflecting, among other things, the workings of the underlying technologies and the financial and political interests of the businesses or governments that promulgate the technologies. (For a simple but important example, think of the way personal correspondence has been changed by the shift from letters delivered through the mail to emails delivered via the internet to messages delivered through smartphones.) A bias is an inclination. Its effects are not inevitable, but they can be strong. To temper them requires awareness and, yes, resistance.

For much of this year, I’ve been exploring the biases of digital media, trying to trace the pressures that the media exert on us as individuals and as a society. I’m far from done, but it’s clear to me that the biases exist and that at this point they have manifested themselves in unmistakable ways. Not only are we well beyond the beginning, but we can see where we’re heading — and where we’ll continue to head if we don’t consciously adjust our course.

Is there an overarching bias to the advance of communication systems? Technology enthusiasts like Kelly would argue that there is — a bias toward greater freedom, democracy, and social harmony. As a society, we’ve largely embraced this sunny view. Harold Innis had a very different take. “Improvements in communication,” he wrote in The Bias of Communication, “make for increased difficulties of understanding.” He continued: “The large-scale mechanization of knowledge is characterized by imperfect competition and the active creation of monopolies in language which prevent understanding and hasten appeals to force.” Looking over recent events, I sense that Innis may turn out to be the more reliable prophet.

Read More

Hexbyte  Hacker News  Computers Survey of YC female founders on sexual coercion and assault by angel and VC investors

Hexbyte Hacker News Computers Survey of YC female founders on sexual coercion and assault by angel and VC investors

Hexbyte Hacker News Computers

Earlier this year we funded Callisto, a non-profit dedicated to building tech to combat sexual assault and harassment. During their time at YC, we helped Callisto send a survey to 125 of the 384 female founders who have participated in YC. They were asked if they’d ever been assaulted or coerced by an angel or VC investor in their startup career. We also created a formal process for founders in the YC community to report bad behavior by investors.

Today, in coordination with Callisto, YC is sharing the results of this survey with the entire YC founder community and the startup community at large. Based on these results, we call upon the entire investor community to redouble its efforts to change this dynamic and abuse of power in the VC/angel investment community. YC has a zero-tolerance policy for inappropriate behavior and will ban any investor who acts inappropriately from our community.

Here are the results of the survey:

  1. 88 YC female founders completed the survey

  2. 19 founders experienced one or more inappropriate incidents by angels or VCs:

    • 18 experienced unwanted sexual overtures or sexual badgering
    • 15 experienced sexual coercion or quid-pro-quo
    • 4 experienced unwanted sexual contact
  3. When founders did report, their main reason was to protect others:

    • “I wanted to make sure that other founders funded by this VC would NOT be in contact with this person, so I shared.”
    • “I wanted other people to avoid being preyed upon by the same people.”
  4. When founders did not report, their main reason was to protect their company, or fear of retaliation:

    • “Did not want to endanger my company’s funding prospects”
    • “I was afraid of the consequences for my ability to get future funding.”
    • “VCs would penalize women for coming forward by icing them out of social and professional situations and denying them funding opportunities, meaning the bad behavior rarely got outed.”

Here’s what YC is doing to combat harassment in the investor community:

  • If you are a YC founder who wishes to report inappropriate behavior by an investor, we have reporting system inside of Bookface (our website for YC founders). You can report at any time, even years after the incident took place. The report will remain confidential. We encourage other investors to set up similar reporting systems.

  • We will also work with and support any YC founder who wants to take actions above and beyond reporting this behavior to YC.

  • We will iterate and call more attention to our reporting process in order to encourage more use of our reporting tool.

  • We will continue to fund startups/non-profits that combat the unfair treatment of women in the workplace. In addition to funding Callisto, we have also funded tEQuitable who is building a third-party, tech-enabled Ombuds platform for companies that addresses issues of bias, discrimination, and harassment in the workplace.

Here is what Callisto is doing to combat harassment in the investor community:

  • Later this fall, they are launching Callisto for founders. Callisto detects serial perpetrators of sexual coercion and assault, and connects survivors to each other and their options for taking action to protect their community.

  • Founders will be able to use Callisto to securely store the identities of perpetrators of sexual coercion and assault. These identities will be encrypted in a way that not even the Callisto team can view. If multiple founders name the same perpetrator, they will be referred to an attorney who can then decrypt the founder’s contact info and reach out to provide them with free advice on their options for coming forward, including the option to share information with other victims of the same perpetrator.

0% of female founders should be ever be harassed, coerced, or experience unwanted sexual contact by investors.

Callisto chose to send the survey to the 125 founders who signed up for the YC female founder email list. They choose this group under the assumption that these founders would welcome being reached out to for the survey because they had signed up proactively to this email list.

Sign up for weekly updates from Y Combinator.

Read More

Hexbyte  Hacker News  Computers Using /proc to get a process’ current stack trace

Hexbyte Hacker News Computers Using /proc to get a process’ current stack trace

Hexbyte Hacker News Computers


The file covered in this article, /proc//stack, is the one that motivated me to learn more about /proc and get The Month of Proc.

It’s such a useful thing when you’re unaware of what is the state of a given process. Meanwhile, I’ve noticed that it’s not very well known by people getting started with Linux.

Hexbyte  Hacker News  Computers Illustration of how the process stack can be inspected

Here in this post, you’ll get to know more about how procfs can gather a process’ stack trace, as well as get an idea of its usefulness.

A process that blocks

To kick things off, let’s start with the tailoring of a process that blocks – a TCP server.

In its most simplistic form, we can have a single-threaded TCP server that just receives traffic in a given thread and then processes its results.

Hexbyte  Hacker News  Computers Illustration of TCP server blocking the main thread

Naturally, there are two places where we can see the server blocking: at the accept(2) phase, of the read(2) phase – the first blocks until a client finishes the TCP handshake; the second, until data is available for read.

Here’s how a simplistic implementation in C would look like considering just the first blocking part (accepting):

 * server_listen takes care of setting up the
 * passive socket that receives incoming TCP
 * connections.
 * Returns the file descriptor corresponding to
 * the passive socket, of -1 in the case of
 * error.
 * See https://ops.tips/blog/a-tcp-server-in-c/#creating-a-socket
 * for a reference implementation.

 * server_accept_and_close accepts connections that
 * finish their TCP handshake through the provided
 * @listen_fd argument.
 * Once the connection is `accept`ed, it gets closed
 * immediately.
server_accept_and_close(int listen_fd)
	int                conn_fd;
	int                err;
	socklen_t          client_len;
	struct sockaddr_in client_addr;

	client_len = sizeof(client_addr);

	printf("Accepting connections ...n");

	// Accept connections from the completed
	// connection queue (pops the latest conn
	// that succesfully finished the 3-way
	// handshake).
	// Given that the queue might be empty, it
	// waits (i.e., blocks) until there's a connection
	// there.
	err = (conn_fd = accept(
	         listen_fd, (struct sockaddr*)&client_addr, &client_len));
	if (err == -1) {
		return err;

	printf("Client connected! Going to close now.n");

	// Mark the connection as closed so that we
	// can get back to accepting new connections.
	err = close(conn_fd);
	if (err == -1) {
		return err;

	return 0;

 * main execution - creates a passive socket
 * bound to a specific port that keeps receiving
 * incoming connections, accepting them and then
 * marking them as closed immediately.
main(int argc, char** argv)
	int err;
	int listen_fd = server_listen();

	if (listen_fd == -1)
		return 1;

	for (;;) {
		err = server_accept_and_close(listen_fd);
		if (err == -1)
			return 1;

	return 0;

If you’re not into how a TCP server can be implemented in C, make sure you check A TCP Server in C for a complete description of it.

Run the server, and then see it blocking!

Viewing the process kernel stack trace

Once the server is blocked, we can jump into /proc and check out what’s going on in the Kernel and figure out that it’s blocked on the accept syscall:

# Gather the in-kernel stack trace of
# the `accept.out` process (the simplistic
# TCP server that we're running).
cat /proc/$(pidof accept.out)/stack
[<0>] inet_csk_accept+0x246/0x380
[<0>] inet_accept+0x45/0x170
[<0>] SYSC_accept4+0xff/0x210
[<0>] SyS_accept+0x10/0x20
[<0>] do_syscall_64+0x73/0x130
[<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<0>] 0xffffffffffffffff

Although it might look like a weird stack trace at first, the structure is very straightforward to reason about.

Each line represents a function that was called (from looking at the stack calls), having the first part, that [<0>] thing, being the kernel address of the function, while the second, that do_syscall_64+... being the symbol name with the corresponding offset.

If [<0>] looks weird (like, not an actual address at all), it’s because it’s intended to be like that.

When fs/proc/base.c#proc_pid_stack (the method that gets called by the /proc implementation of the virtual filesystem) iterates over the stack frames, we can see that it hardcodes [<0>] as the address to be displayed:

 * Iterates through the kernel stack frames of
 * the current task, displaying the kernel 
 * addresses of each function, as well as
 * their symbol name and offset.
static int proc_pid_stack(struct seq_file *m, struct pid_namespace *ns,
			  struct pid *pid, struct task_struct *task)
	struct stack_trace trace;
	unsigned long *entries;
	int err;
	int i;

        // Allocate some memory so that we can have
        // in our execution the whole stack of the
        // process (up to a given depth).
	// The first argument to the kmalloc
	// is the size of the block to be allocated.
	// The second argument is allocation flag.
	// GFP_KERNEL means that allocation is performed on
	// behalf of a process running in the kernel space.
	// This means that the calling function is executing
	// a system call on behalf of a process.
	// Using GFP_KERNEL means that kmalloc can put the
	// current process to sleep waiting for a page when
	// called in low-memory situations.
	// See https://elixir.bootlin.com/linux/v4.15/source/include/linux/gfp.h#L219
	entries = kmalloc(MAX_STACK_TRACE_DEPTH * sizeof(*entries), GFP_KERNEL);
	if (!entries)
		return -ENOMEM;

        // With the space properly allocated, we can now
        // prepare the `stack_trace` struct and pass
        // it down to the function that will get that
        // for us.
	trace.nr_entries	= 0;
	trace.max_entries	= MAX_STACK_TRACE_DEPTH;
	trace.entries		= entries;
	trace.skip		= 0;

        // Make sure that we have mutual exclusion in
        // place.
	err = lock_trace(task);
	if (!err) {
                // Capture the stack trace!
		// https://elixir.bootlin.com/linux/v4.15/source/arch/x86/kernel/stacktrace.c#L69
		save_stack_trace_tsk(task, &trace);

                // Iterate over each frame captured.
                // *************************
                // HERE is where the `[<0>]` is hardcoded.
                // *************************
		for (i = 0; i < trace.nr_entries; i++) {
			seq_printf(m, "[<0>] %pBn", (void *)entries[i]);

	return err;