That sounds interesting! Have you considered open sourcing your work?
I've been working on similar things on and off for a long time (specifically a sort of meld between Workflowy and spreadsheets, but supporting DAGs), but it takes significant effort to reach a stage where tools are useful and reliable...
As a complete bystander there may be history I'm completely ignorant of, but in Gogs issue 1304 Unknwon themselves wrote:
"In my point of view, it's a sign of success of Gogs that Gitea forked it. Gogs is under MIT license and there is no problem with me totally that Gitea is developing its own version. It happens often in open source community(when you are not satisfied with upstream version, I fork a lot actually)."
In the same issue comment Unknwon also states that they believe Gogs and Gitea to have fundamental philosophical differences, and finishes off with thanking everyone and wishing happy coding.
I don't know all the facts and Unknwon's personal view may have changed in last 18 months, but just judging by the philosophy of the original author and maintainer of Gogs the lack of courtesy, tact and respect of their roots that you refer to might be an opinion of yours that Unknwon doesn't share. If that is so, then what do you mean they lack courtesy, tact and respect towards?
Of course, if I'm mistaken or there are more recent opinions of Unknwon's that contradict this, then please disregard this comment.
It would be so great if Sean got to work full time on hyper, but of course I understand that he is needed elsewhere at Mozilla and he's doing a great job with the time he has. I would hazard a guess that there are so many besides me waiting for the upcoming HTTP client/server improvements that it would probably not be the worst idea if Mozilla (or some other org betting on Rust) threw some money at it.
I'm extremely grateful to everyone working on Rust and its ecosystem (paid or otherwise) for the work that you do. It sure sounds cheesy, but after trying lots of stuff over the years, Rust feels like coming home. There, I said it. I'm pushing it at my employer, and for every piece of tooling or important crate that matures, it gets easier to evangelize.
Yeah, I hear you. That said, money is being thrown, but at tokio itself, rather than at hyper. You have to finish the lower bits before the higher ones.
I'm in a lucky position to be able to choose the tools I use at work. For certain parts, Rust's been already a great help and right now I wait tokio and hyper/tokio more than I waited for Super Nintendo when I was a child. They will be an enormous help when refactoring the current services. I'm pushing myself to learn more so I could be helping with these projects.
That said, thank you for the whole Rust team. It hits the sweet spot being fast, not eating so much memory, being pleasure to write and having amazing tooling around it.
I love Firefox and use it heavily every day as main browser for 99% of web browsing, which is a big reason why I also donate money to Mozilla.
However, Sync has a dissappointing property: Despite the (simplified) claims on the most readable user facing pages about it, it will not sync your open tabs across devices. It will only sync your last 100 (?) active open tabs on each device.
I will happily admit to being an outlier with >100 tabs per device, and I'm very grateful to Mozilla for this free service they're providing me. I also understand that any such service may need an upper limit.
However, had there been any mention of this fact anywhere other than the bugzilla issues I found while trying to figure out why Sync was (in my perception) not working properly, I wouldn't have tried it. I'd love it if they were just accurate about this in their feature description.
I'm really looking forward to when rustup.rs is stable (atleast for Linux)! I'm trying to push Rust at work, and it's one of those polishy things that would help.
Unfortunately, last time I checked development (on issues blocking the initial stable release) seemed to have slowed as of late, but I should be helping out instead of whining - the Rust community is doing great work!
Summer is definitely a slow time for us, lots of folks taking well-deserved vacations and lots of effort being diverted into organizing our three Rust conferences taking place this year, which I might as well plug while I'm at it:
Does the general admission ticket cover both day 1 and day 2 for Rust Belt Rust? Sorry for hijacking. I have issue with getting response from organizers from other conferences in the past so thought I would just leave an ask here.
I've been using it on my Mac since the post about it on here a few months ago and I've had no issues at all, though I haven't tried to do anything strange/difficult with it.
I write high level automated tests immediately at the beginning of a project, which have several upsides:
They can be read almost like project requirements, so they double as validation for solving the problems in the reqs.
They only use the outermost APIs of your code, which will change much less than internal module APIs, and so won't inhibit changes and experimentation as much.
They enable you to automatically test your code in the "real" scenarios that your project reqs describe, instead of just module-level tests that may not catch bugs in API usage of those "real" scenarios.
Later on in the project, as larger internal modules crystallize, you isolate those modules with their own outer APIs and write automated tests for their APIs.
Yes, this has downsides. High level white box testing exclusively during early stages obviously won't catch all your internal error cases early. However, I have found them to have superb ROI, especially in projects where time constraints have required pragmatic approaches.
I have a feeling that that's the completely wrong way to look at it, although I'm happy to be corrected if I'm wrong.
Today, GPU vendors write big, complex, closed-source drivers offering high-level APIs that as a result are buggier and harder for FOSS-developers to keep up with and make FOSS replacements for.
With Vulkan, GPU vendors should write smaller/simpler drivers, in theory making it easier/cheaper for them to provide good drivers and probably reducing the amount of work needed to produce a replacement FOSS-driver.
The complexity and the high-level APIs is supposed to move out of the driver and into libraries and engines, and many such will be FOSS and probably more portable than the FOSS kernel drivers can be. Please correct me if I'm wrong, though, as I'm not a graphics guy, but I was happy for FOSS when I first read about Vulkan.
I'm not a financial expert and can't speak to what's true or not, but here's [1] a short interview with Swedens former Tax Agency chief who was apparently part of a small task force to evaluate Greece's tax collection and aid in its improvement.
He claims that removing corruption is not the only problem, and that the rest of the EU are underestimating the lack of tax collection competence with regards to modern methods and processes, as well as the powerlessness and political isolation of the Greek tax chief, making his/her job impossible - e.g. by not even being allowed to pick his/her own employees.
Again, I don't know what's true or not, just providing the opinion of a former Tax Agency chief of a country that collects a lot of taxes and who apparently had the opportunity to take a closer look at Greece's tax collection.
Google Translate does a decent job with the article translation.
Songkick is one of those services where I feel that it's a fair deal surrendering my data (listening habits) because I get a service in return that's really valuable to me. When I tried it out the first time I was surprised at how good recommendations I got for my geographical vicinity (Sweden/Denmark), as many services - naturally - focus on the US only. Three cheers from me to SK.
I've been working on similar things on and off for a long time (specifically a sort of meld between Workflowy and spreadsheets, but supporting DAGs), but it takes significant effort to reach a stage where tools are useful and reliable...