sebcat

> Was: Re: bug#30626

    (seq-doseq (_ (stream-range 1 1000000)) nil)

I guess it depends on how you define "know", but there are implicit rules.

    $ cat foo.c
    #include <stdio.h>
    int main() {
      printf("Hello\n");
      return 0;
    }
    $ cat Makefile
    foo: foo.c
    $ make
    cc -O2 -pipe    foo.c  -o foo
    $ ./foo
    Hello

Which was nice to be able to observe, because the code didn't need to do many small allocations.

It breaks expectations. I havn't looked at it recently, but it used to be the case that hosting user submitted SVGs on your domain could yield JS-execution in the origin context. Embedding or iframing without sandbox isn't/wasn't secure either.

A quick google search on SVG XSS gives:

https://hackerone.com/reports/148853 https://phabricator.wikimedia.org/T85850

What's the employer payroll tax?

For comparison: in Sweden, the employer payroll tax is 31.42%, the income tax is ~30% (depending on where you live) and the VAT is 25% for most goods (food is 12% IIRC).

The employer payroll tax is a bit interesting. As an employee you never see that money, but you more or less pay it (lower wages).

Is it theirs to open up though? When I last looked at it, it seemed as if most of their tech was Ambarella SoCs. Doing a quick search now, it seems they went with Socionext for Hero 6.

Even if they could open it up, it would be a non-trivial cost to support. Multiple products, probably multiple breaking API changes between firmware releases, ... It would probably have to be on a partnering program basis, and for that you need partners willing to share the costs.

As for lowering the price... The market is becoming saturated, competition increased and cheaper alternatives have been popping up. Lowering COGS is hard. GoPro grew up and cornered the market for a while. In doing so, they grew in the environment they were in, but the environment changed and now they have to adopt to the new conditions. That's easier said than done.

I'd say they'd have to broaden their product portfolio in order to avoid/get out of stagnation and decline. I think that was their thought when going into the drone market, but it didn't go well from what I understand. There's other markets for products built around optical sensors (surveillance/security, "smart" sensors w/ computer vision, ...).

Supporting an open developer program is probably not a viable thing for them to do right now.

It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.

Let's say there's a COBOL -> C/C++/Rust/someotherfancylang transpiler. Maybe there is one, maybe not. Would it make sense for a bank to invest in something like that, or is there really no incentive to do so? Why would there be an incentive for a startup to do so, but not for a bank?

-- Carl von Clausewitz (On War?)

Booting from ROM is one thing. Loading something from tape, that's another story.

[1] http://www.inf.puc-rio.br/~roberto/lpeg/

I've used it in the past to get an overview of what gets passed to SSL_write, SSL_read: https://github.com/sebcat/openssl-hook

Not saying that I agree with that, just presenting a different point of view.

I have some of my savings in index funds. The low fees, the risk profile (if that's a proper term for it in English) and historical performance (which is not a guarantee for future performance) of certain indices is what I like about them.

If I create an index consisting of Company A, B, C, with 40% A, 30% B, 30% C and call that index "the sebcat index" others may sell sebcat index funds consisting of company A, B, and C stocks at those proportions. Of course, that's a bit too arbitrary. Normally you would have an index based on e.g., the N largest companies on a specific market/region. The index may be adjusted over time depending on market cap or something else, funds may not follow the index exactly, but that's the gist of it, to the best of my knowledge (see caveat). It's not in itself bound to geographical regions, though if you buy funds tracking foreign companies you should be aware of currency effects, politics &c (though local companies could be affected by that as well of course).

Look up a couple of indices (e.g., MSCI indices), then find what index funds on your exchange tracks these indices. Look up what the funds consist of exactly. If you compare two different funds tracking the same index, they should have similar performance over time. Buy one or two per index. The fees should be relatively small, 0-0.4%.

If you expect a crash to happen, or you see a crash happening that is not likely to end soon, sell any index funds affected and maybe put the money in interest funds, or gold, or something that you believe will not be as affected by, or benefit from the current situation on the market. Then buy back when (or if) the market goes up again (depending on your time frame).

I do not see this in the code linked to from the article.

Each ChatHandler has three (buffered) channels: outgoingInfo.channel, sockChannel, readErrorChannel (not buffered)

There are some things that could cause bottle necks that are not related to goroutines and channels: Every published message calls GroupInfoManager.GetUsers to get a list of all the users in a group. That can be expensive (I don't know if it is or isn't). And then for every user in a channel, their userOutGoingInfo is retrieved.

I would suggest profiling before switching languages.

EDIT: changed "benchmarking" to "profiling" EDIT2: changed "are likely to" to "could" (... cause bottle necks) since I don't know

I had a specific thing I needed to do, gumbo-parser was a good match, I poked at it a little and moved on. It started with this[1] commit, then I did some other work locally which was not pushed because google/gumbo-parser is without an owner/maintainer. There are a couple of forks, but no/little adoption it seems.

[1] https://github.com/sebcat/gumbo-parser/commit/c158f8090c2df0...

Those are two very different things. Focusing on one of them doesn't automatically benefit your efforts on the other.

Jaggery seems to be 50% sucrose, and honey is mostly glucose and fructose. Shouldn't it have the same effect on blood sugar levels?