Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re:Companies Selling Actually Free Software? (Score 1) 290 290

Yes, regarding the problem of selling free software, I'd specifically ask RMS:

Would you support a licence that allowed free redistribution of modified or unmodified source and build systems, but removed the freedom to run (Freedom 0) for non-development uses? The license would specify a default distribution of a use-fee up the chain of fork parents, though a differing split could be negotiated. For example, would you have had trouble with that non-free printer driver back in the 80s if you had been able to tinker and spread your version, even though you and others had to pay to use it, with perhaps some of this money flowing to you for your improvements.

Comment Allow redistribution, Charge to run, Reward forks (Score 1) 85 85

  1. Make the source public and allow public forks.
  2. But require purchase of a license file in order for users run it for "production" purposes (no Freedom 0).
  3. Allow forkers to negotiate a revenue split, shared up the fork tree.

Comment Re:Flawed statistics are flawed (Score 1) 114 114

Spam mail isn't down. Legitimate (for varying definitions of legitimate) mail is up.

The opposite could also be true: As the young move from email to social apps, spammers have quickly followed. Just like how spam disappeared from USENET faster than legitimate posts as USENET began to die. I'd like to see evidence that pointed to the correct reason.

I get about 15000 spam emails a month.

Comment Re:And who is at the bottom? (Score 2) 432 432

If government imposed artificial scarcity and price controls is such great idea for taxis, then why shouldn't the same model be good for other areas of the economy? Why shouldn't there be a "grocery store medallion" to limit the number of stores, jack up prices, and prevent them from having to compete? How about programmers? Should there be a "programmer medallion" to limit the number of people allowed to write code?

I suppose the difference is that taxi driving is relatively unskilled (especially if there's no route-knowledge test — less important now that there's sat nav). Supply constraints aim to give these unskilled people an adequate full-time job and wage, which may be more socially desirable than open-slather combined with welfare support. But the unintended consequences have concentrated the power and profits in pimp-like medallion owners, who sub-contract to the drivers. Perhaps the solution is an Uber-like system combined with quotas.

Comment Re:GPL and copyright (Score 1) 189 189

The trouble with that is, when given the option of paying or not, the vast majority of users will choose "not," at least given a wide enough target audience (some niches may be filled with more generous people of course..)

I agree that it's hard to sell application software to individuals. But it's much easier to sell application software to businesses (including software that helps make individuals money), and to sell system software (components and tools). Business have both the money and a desire to preserve their reputation, so most will go legit even if the software's open, especially if support comes with the purchase.

So there's no reason why this sort of software shouldn't be open, particularly as such customers are the ones who are most interested in tinkering. I doubt RMS would have started GNU/FSF if that printer driver had been open source but not free of charge.

Comment Re:GPL and copyright (Score 2) 189 189

It's the best part of twenty years since I wrote any software where we cared about copyright. Everything I've written since then has been useless without our hardware, and that's where we make the money.

You're lucky that you've got closed hardware to act as a dongle for your software. But does this mean people who want to earn a living writing software for open hardware are SOL? I think such people should be able to put a (fixed, non donation) price on use of their work, but at the same time keep the software open so that users can tinker.

Comment Re:Idiots (Score 1) 221 221

Because of predicable data rates, you wouldn't of course need Tx buffer exhaustion interrupts. You can just do a countdown on timer interrupts. Same for receipt of the header. So the only special thing you'd need would be either an interrupt or a poll for receipt of the first byte.

Comment Re:Idiots (Score 1) 221 221

Thanks for those interesting details on how big routers work. Looks like they're optimized for throughput not latency. Though if as you say normal link loadings mean that many packets need to be buffered, pipelining packets isn't going to improve latencies.

But I don't think there's any reason x86 severs, which make up many of the nodes at both ends of a path, couldn't be set up to reliably pipeline packets. A 1500 byte packet on a 1Gbps link is received in 12us, a 20 byte header in 160ns. To reduce latency the processor needs to work out the packet's destination within this interval, which is about 30k instructions. This shouldn't have to touch RAM, because I'm sure the routing tables of all but the most connected hubs can fit in the 25-45MB L3 caches of current Intel server CPUs.

The sequence would be: get interrupted when a header arrives, work out the destination link, initiate a DMA to that link that contains the new header followed by whatever part of the packet has been received up to then, set up interrupts for when the Tx buffer is nearly exhausted, and on each of these DMA whatever else has been received up to that time.

Comment Re:Idiots (Score 1) 221 221

Each core has its own registers, L1 cache, and L2 cache. So if one core were to be devoted to the OS (or just to interrupt processing, which the x86 can do), there'd be either no context switches, or context switches that fit in the caches and so hardly have to touch the RAM. Dedicated cores would especially make sense on servers whose job is to route, filter, and cache traffic, and even on application servers.

Comment Re:Idiots (Score 1) 221 221

Not really. The x86 architecture can't handle the interrupts. That's why modern cards don't interrupt on every packet received.

What, even with so many cores available now that one could be reserved as a network co-processor? If the bottleneck is instead another aspect of the architecture, I'm sure such a trillion dollar industry can work out how to fix it.

As well as handling interrupts on header receipt, you'd also have to handle interrupts on near exhaustion of transmit buffers, so packets can be pipelined in chunks between ports.

Comment Re:Idiots (Score 1) 221 221

There are problems with this approach. First of all higher bandwidth of the interface the less you get out of it.. A 1500 MTU packet vs 10GB or 100GB PHY is not going to be detected by the most 1337 gamer with her 8000000 dpi x-ray laser mouse and super mega ultra polling keyboard.

Transmitting a 1500 byte packet after the 20 byte header has been received reduces latency by a factor of 75. Given enough hops, this can be significant.

The bigger issue is this only works reliably when switching between instantaneously free/equal capacity links otherwise if you don't buffer at all your going to suffer some serious packet loss.

As I said in my other reply, if the incoming and outgoing link speeds don't match, can't you only buffer until time when the outgoing packet can be transmitted continuously? For example, if the outgoing link is twice the speed, starting to transmit when half the packet has been buffered.

Comment Re:Idiots (Score 1) 221 221

Thanks for that info. Looks like network chips for PC/server architectures need to start supporting interrupts on header receipt.

Even if an outgoing link is faster than the incoming one, time can still be saved by starting to transmit the outgoing header as soon as the whole packet can be transmitted continuously. Even sooner if the physical protocol supports gaps, or when wasted bandwidth is less important than reduced latency.

Comment Re:Idiots (Score 1) 221 221

Buffering and switching latency is the main source of delay, not signal latency in the copper and fiber. Microwaves would do exactly nothing to improve the switching and buffering latency. If anything they'd make it worse: light in fiber travels much further than line-of-sight microwave before it has to be regenerated with another delay.

There's not much delay for a simple repeater compared to a node that must read the packet so it can re-route it.

My question would be: To what extent do Internet nodes (with empty buffers) start forwarding a packet after reading its IP header, rather than waiting for the whole packet to be received? For example, does Linux support this? Not doing this ubiquitously would really increase end-to-end packet latency, which the cited paper argues is more important than speeding up protocols for getting a lower-latency Internet.

Comment Re:Fuck you. (Score 1) 618 618

As well as being on the side, there are also several search engine ads placed at the top of the main result list, forcing you to scan past them to read the first organic result. They're also coloured, which draws your eye to them.

But my main thrust was that even if they're out of the way, they're still ads with agendas to relieve you of your cash.

Search engines should provide "view all relevant ads" link that even those using ad-blockers can see. This would allow such people to see what's on offer when they are in a buying mode, without having to disable their blockers, refresh and page to see a good selection of ads, then re-enable their blockers.

Comment Re:A poorly made point, but still a point (Score 1) 618 618

So my question to all of those infuriated by those content producers who would "dare" to try to protect their ads is this: what viable alternative do you suggest?

Here's the alternative to advertising on which I've been working. Advantages: no cost to users, publishers earn money from their content rather than the stuff around it, and allows monetization of unbiased content (that unlike ads tries to tell the whole truth).

Yes, this is an ad. But because it's on-topic and in some way solicited, I think it's acceptable, and shouldn't be equated to something intrusive.

Syntactic sugar causes cancer of the semicolon. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982