InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises. Learn more →
Pear Alternatives
Similar projects and alternatives to pear
-
libdatachannel
C/C++ WebRTC network library featuring Data Channels, Media Transport, and WebSockets
-
openmiko
Open source firmware for Ingenic T20 based devices such as WyzeCam V2, Xiaomi Xiaofang 1S, iSmartAlarm's Spot+ and others.
-
SonarQube
Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.
-
-
Ory Keto
Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.
-
spchcat
Speech recognition tool to convert audio to text transcripts, for Linux and Raspberry Pi.
-
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
-
-
CppCoreGuidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
-
-
cargo-crev
A cryptographically verifiable code review system for the cargo (Rust) package manager.
-
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better pear alternative or higher similarity.
pear reviews and mentions
Posts with mentions or reviews of pear.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-04-08.
-
Hacker News top posts: Apr 8, 2021
A simple C implementation to stream H.264 to browser using WebRTC\ (61 comments)
-
A simple C implementation to stream H.264 to browser using WebRTC
I think there's some truth in what as-j is saying. Rust binaries (and C++ ones) tend to be larger than C ones. I think the major reasons are (a) Rust dependencies being statically linked due to a lack of ABI stability, (b) inclusion of portions of the (statically linked, see a) Rust standard library used by the program where C code uses libc, (c) code bloat due to monomorphization, (d) the ease of just using a full-featured library where someone writing in C might cheat a little bit. As an example of what I mean by the last point, see sdp_attribute_get_answer in this codebase. [1] It's writing JSON, but it doesn't use a JSON library that actually escapes the included string. It just assumes the included string doesn't have a quote character in it. Is that assumption valid? Will it always be valid? I'm not sure on quick inspection.
There are ways around all of these:
* a. Static vs dynamic linkage: in an embedded system, it'd be reasonable to just produce a single userspace binary that does everything. It can change its behavior based on argv[0]. I think this is not too unusual for constrained systems even with C binaries. Eg busybox does it. If you only have one binary, you don't need dynamic linking. Also, I think it's not strictly true that Rust doesn't support dynamic linking. I think you can dynamically link everything if you ensure the whole system is built with the same compiler version.
* b. Standard library. You don't have to use it at all, or you can use it sparingly, paying only for what you use.
* c. Monomorphization. You could write (for example) a Go-like map [2] rather than relying so heavily on monomorphization. I'd love to see someone take this idea as far as possible; it might be a good idea for a lot of non-inner-loop code in general, not just on tight embedded systems.
* d. Using full-featured libraries. Obviously no one is making you do this; the same cheats available in C are available in Rust.
but in fairness, the further you go down this path, the further you are from just being able to just take advantage of the whole Rust ecosystem.
Personally, I'd still rather develop or use a #![no_std] Rust codebase than a C one. Memory safety is important to me. IOT devices are no exception to that. Their security is historically horrible but I'd like to change that.
[1] https://github.com/sepfy/pear/blob/b984c8dccaafdcdd1b181786a...
[2] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
-
A note from our sponsor - InfluxDB
www.influxdata.com | 30 Jan 2023
Stats
Basic pear repo stats
6
585
1.3
4 months ago
sepfy/pear is an open source project licensed under MIT License which is an OSI approved license.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com