stevemk14ebr

lasers that make clouds, I assume - cloud lasers

what makes it 'clearly not right' and why is it 'obviously the account holders fault'? Victim blame much?

And my more sophisticated library, https://github.com/stevemk14ebr/PolyHook_2_0

insecurity lol. You made an unbased claim and retort with 'insecurity' when challenged. All operating systems have pros and cons, and people have preferences.

Look into Nim or Zig instead if you're coming from C++

If you want to be on the forefront of learning, well, that takes just a tiny bit of effort on your part.

switch to 12 hr time :)

"What I got right...Using capitalization for the public/private distinction in functions, methods, variables, and fields"

I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do this in a non-manual fashion you're required to parse all of the code exactly perfectly (ASTs and such). Even go itself has not figured out how to do this, rf is still experimental and not complete: https://pkg.go.dev/rsc.io/rf.

Example use case: https://github.com/golang/go/issues/46792

I much prefer the non-viral public/private attributes other languages use.

"Unfortunately, most WHIP implementations are highly complex and require modern C++11 or C++14, or RUST...To meet FFmpeg's requirements, this PR contains just C code. And we have rewritten the WHIP and WebRTC protocol stack using only around 2k lines of C code."

Where is the section on the security audit? For a protocol accepting remote streams especially this seems like a vector for exploitable bugs to be introduced unintentionally.

Social connections being lost is not something easy to compensate for. Those often take a _long_ time to grow organically as well.

if us-east-1 "goes away" most of us have bigger problems than data recovery

you've got to be very disconnected to not know that 3.5mm jacks have been removed from most modern phones by now (a terrible choice, I agree)

no linuxserver docker image yet unfortunately

When Chromecast first lost the ability to adjust volume from my smartphone, I was very confused. Took me at least a week or two to find out that it was removed intentionally and wasn't a weird bug. That bothered me.

Touch me like that and conversation is over.

Their comment is illuminating the current way things work, that's hardly disgusting. That status quo you may not like, but that's saying nothing about the author of the comment, or their views on that fact.

Your anger should be at the system, not the author pointing out a fact.

Wait till you do the math on how much money that 1% has relative to the 99%.

this is a huge issue for me as well, really dumb

This issue for myself and many others is it makes something that used to be transparent, entirely unsupported. The UX is unambiguously worse. I could trust signal to upgrade my texts for me when possible, or not when my contacts were SMS. I don't care about always being encrypted 100% of the time. Signal was that perfect tradeoff between privacy, and ease of use, which is exceptionally rare. Providing this tradeoff is what made them popular, them going against it is counterproductive and will hurt them badly. I know this because now I'm considering leaving myself.

It is very disappointing there are no embeddable, performant wasm runtimes. The language is perfect for embedded systems, it's a near asm level sandbox. But there's no good no_std or limited dependency runtimes! If wasm is to grow, it should work on this use case.

I should be able to provide platform APIs to allocate memory, maybe do some floating point math, and then that's about it. Additional features would just be giving some additional API implementations the runtime needs to interact with the host machine.

Context: this was a huge barrier for me on my project https://github.com/mandiant/STrace/blob/16859a811e4af7c68259...

There's a logical fallacy called the slippery slope. It's not an effective thinking strategy. Cloudflare simply chose not to protect a site full of bullies. As is their right. They hardly silenced anyone.

This would be kind of huge if this actually happened. As a researcher in the field, I hope someone can finally do this, please.

We agree! I'm not calling dtrace bad for the record, it's awesome. My issue is just with the language users are forced to write in not being expressive enough (specifically on windows at that). If fixed length loops and user defined functions were added, it would be quite a lot easier to implement advanced scripts.

Example from the doc. Probes not being allowed to call other system routines to avoid reentrancy. Dtrace avoids this architecturally, as your link says. I disliked this, so I chose the alternative, which so happens to be mentioned in the same document. My system detects reentrancy and avoided calling probes when it's determined the caller was itself a probe.

I simply chose different constraints. It 'not being secure' is a facade. It's not meant to be, I could make it so though, if I wanted to. I bothered with the entire rust + wasm implementation specifically to show that this argument of not being secure' because I didn't use the D language was untrue. Browsers themselves execute untrusted code via wasm. If the concern is the halting problem, then just use wasm with bounded loops.

I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another.

If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load.

Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.

Yes, you do misunderstand. The D language is terrible, it has no loops, no functions, it is not a usable language beyond basic scripts. The _good_ part of the windows implementation is the kernel interfaces, which is what my design uses. The entire point of this research was to discard the D language.

My implementation(s) allow you to use C++ 17, or Web Assembly instead. These are significantly more powerful languages. The Web Assembly scripts are a demonstration of using the same 'safe' architecture as DTrace. While the C++17 DLL system is a demonstration of an 'unsafe' but more powerful design.

If you think DTrace can't crash the system, you are mistaken.

Dtrace was added to windows before the bpf system was. This is a bit over two years old now.

While amazing, this Microsoft implementation has some limitations. See my adaptation / reimplementation here https://github.com/mandiant/STrace

From their quote it does represent a big limitation unfortunately. No loops limits the ability to do relatively simple string manipulations and iterate over other object collections where the size isn't statically known. The best you can do is basically manually unroll loops up to a fixed size. For windows dtrace for example it prevents you from writing your own wide to narrow strong routine, as well as doing sub string matches. Also, enumerating bit enums and converting flags to strings. There's many more cases too of course. I can understand the design limitation to some extent. But using the same kernel tracing APIs then extending it with a more powerful, arguably potentially less secure language, was a primary motivator for why I did this research at all. Ebpf for example allows loops. I disagree with you that a reimplementation must follow the complete architecture of the system being reimplemented, that's quite a strict interpretation in my opinion. You're of course entitled to that, I hope it's interesting/useful regardless of terminology :)