3,257,513 events, 1,591,449 push events, 2,464,207 commit messages, 181,759,700 characters
New data: 2021-03-24. See data notes.
Revise historical data: cases (BC, MB, ON, QC); mortality (ON).
Note regarding deaths added in QC today: “8 new deaths, for a total of 10,626 deaths: 0 deaths in the last 24 hours, 6 deaths between March 17 and March 22, 2 deaths before March 17.” We report deaths such that our cumulative regional totals match today’s values. This sometimes results in extra deaths with today’s date when older deaths are removed.
Recent changes:
2021-01-27: Due to the limit on file sizes in GitHub, we implemented some changes to the datasets today, mostly impacting individual-level data (cases and mortality). Changes below:
- Individual-level data (cases.csv and mortality.csv) have been moved to a new directory in the root directory entitled “individual_level”. These files have been split by calendar year and named as follows: cases_2020.csv, cases_2021.csv, mortality_2020.csv, mortality_2021.csv. The directories “other/cases_extra” and “other/mortality_extra” have been moved into the “individual_level” directory.
- Redundant datasets have been removed from the root directory. These files include: recovered_cumulative.csv, testing_cumulative.csv, vaccine_administration_cumulative.csv, vaccine_distribution_cumulative.csv, vaccine_completion_cumulative.csv. All of these datasets are currently available as time series in the directory “timeseries_prov”.
- The file codebook.csv has been moved to the directory “other”.
We appreciate your patience and hope these changes cause minimal disruption. We do not anticipate making any other breaking changes to the datasets in the near future. If you have any further questions, please open an issue on GitHub or reach out to us by email at ccodwg [at] gmail [dot] com. Thank you for using the COVID-19 Canada Open Data Working Group datasets.
- 2021-01-24: The columns "additional_info" and "additional_source" in cases.csv and mortality.csv have been abbreviated similar to "case_source" and "death_source". See note in README.md from 2021-11-27 and 2021-01-08.
Vaccine datasets:
- 2021-01-19: Fully vaccinated data have been added (vaccine_completion_cumulative.csv, timeseries_prov/vaccine_completion_timeseries_prov.csv, timeseries_canada/vaccine_completion_timeseries_canada.csv). Note that this value is not currently reported by all provinces (some provinces have all 0s).
- 2021-01-11: Our Ontario vaccine dataset has changed. Previously, we used two datasets: the MoH Daily Situation Report (https://www.oha.com/news/updates-on-the-novel-coronavirus), which is released weekdays in the evenings, and the “COVID-19 Vaccine Data in Ontario” dataset (https://data.ontario.ca/dataset/covid-19-vaccine-data-in-ontario), which is released every day in the mornings. Because the Daily Situation Report is released later in the day, it has more up-to-date numbers. However, since it is not available on weekends, this leads to an artificial “dip” in numbers on Saturday and “jump” on Monday due to the transition between data sources. We will now exclusively use the daily “COVID-19 Vaccine Data in Ontario” dataset. Although our numbers will be slightly less timely, the daily values will be consistent. We have replaced our historical dataset with “COVID-19 Vaccine Data in Ontario” as far back as they are available.
- 2020-12-17: Vaccination data have been added as time series in timeseries_prov and timeseries_hr.
- 2020-12-15: We have added two vaccine datasets to the repository, vaccine_administration_cumulative.csv and vaccine_distribution_cumulative.csv. These data should be considered preliminary and are subject to change and revision. The format of these new datasets may also change at any time as the data situation evolves.
Note about SK data: As of 2020-12-14, we are providing a daily version of the official SK dataset that is compatible with the rest of our dataset in the folder official_datasets/sk. See below for information about our regular updates.
SK transitioned to reporting according to a new, expanded set of health regions on 2020-09-14. Unfortunately, the new health regions do not correspond exactly to the old health regions. Additionally, the provided case time series using the new boundaries do not exist for dates earlier than August 4, making providing a time series using the new boundaries impossible.
For now, we are adding new cases according to the list of new cases given in the “highlights” section of the SK government website (https://dashboard.saskatchewan.ca/health-wellness/covid-19/cases). These new cases are roughly grouped according to the old boundaries. However, health region totals were redistributed when the new boundaries were instituted on 2020-09-14, so while our daily case numbers match the numbers given in this section, our cumulative totals do not. We have reached out to the SK government to determine how this issue can be resolved. We will rectify our SK health region time series as soon it becomes possible to do so.
i fucking hate blurple jesus christ discord is so uglyt god damn
recolors:D
New Link: My Love Story with Technology. Love stories, those started with hatred… | by Anisha Swain | Coffee with the UI girl | Medium
WORKING TERMINAL
I'm definitely way too excited over this one bugfix, but after a day or two of seething over why I couldn't get a certain keypress event to work properly, only to find that the solution was as simple as changing the textarea tag to an input tag, I can't help but exclaim joyous relief. FUcking fuck me dude.
Now I can start updating the terminal logic with various commands. I also removed the pink marquee from kokuhaku.html, figure it's kinda ugly and pointless for now
Merge pull request #12809 from SimonRichardson/validate-units
The following is ongoing work to validate updating a series on an application. Most of this PR shifts code around to ensure that we can test the updating of a series in a better way, as the application suite currently takes over 10minutes to run. This highlights the awful state that most of these tests are in. We should endeavor to fix this at every possibility, as this is one of the older facades this is going to be a slow process.
The mean of this PR will validate that an application can be updated to a given series based on either the local state for charmstore or local charms or the remote state for charmhub charms. This isn't that far off from what the machine manager facade was tasked to do but in reality, is different enough for the application facade that we have to reimplement it slightly differently.
We need to seriously think about how we allow a set-series for multiple user perspectives. I have an idea of acquiring a machine lock for ALL machines for a given application, but that may be too damaging. Alternatively, we could introduce an application lock and I'm unsure how far down the rabbit hole I want to go with that?
$ juju bootstrap lxd test
$ juju deploy ubuntu --series=bionic
$ juju deploy nrpe
$ juju add-relation nrpe ubuntu
$ juju set-series ubuntu focal
Check to see the series has been moved to focal. Ignore the charmurl
and charm-origin
in this case, this will be solved in a future PR.
$ juju mongo
$ db.applications.find().pretty()
{
"_id" : "dfa8a921-b699-4cf4-8a55-253aaf4754e7:ubuntu",
"name" : "ubuntu",
"model-uuid" : "dfa8a921-b699-4cf4-8a55-253aaf4754e7",
"series" : "focal",
"subordinate" : false,
"charmurl" : "ch:amd64/bionic/ubuntu-19",
"cs-channel" : "stable",
"charm-origin" : {
"source" : "charm-hub",
"type" : "charm",
"id" : "DksXQKAQTZfsUmBAGanZAhpoS4dpmXel",
"hash" : "6bf4a85e0a92b6f4a5f58706c0f288c7657abda776c759da13d0409ed6656cae",
"revision" : 19,
"channel" : {
"risk" : "stable"
},
"platform" : {
"architecture" : "amd64",
"os" : "ubuntu",
"series" : "bionic"
}
},
"charmmodifiedversion" : 0,
"forcecharm" : false,
"life" : 0,
"unitcount" : 1,
"relationcount" : 1,
"minunits" : 0,
"txn-revno" : NumberLong(5),
"metric-credentials" : BinData(0,""),
"exposed" : false,
"scale" : 0,
"passwordhash" : "",
"txn-queue" : [
"605b683f4407403a33b31ad6_e51cce2f"
]
}
{
"_id" : "dfa8a921-b699-4cf4-8a55-253aaf4754e7:nrpe",
"name" : "nrpe",
"model-uuid" : "dfa8a921-b699-4cf4-8a55-253aaf4754e7",
"series" : "focal",
"subordinate" : true,
"charmurl" : "ch:amd64/bionic/nrpe-70",
"cs-channel" : "stable",
"charm-origin" : {
"source" : "charm-hub",
"type" : "charm",
"id" : "I4k7tN5SKZr4aYJ8b1GzufIDUQfievyT",
"hash" : "1dc14c5215288cc63b19610e1596bef4f447e29ee2655b34b6d248689f19cce7",
"revision" : 70,
"channel" : {
"risk" : "stable"
},
"platform" : {
"architecture" : "amd64",
"os" : "ubuntu",
"series" : "bionic"
}
},
"charmmodifiedversion" : 0,
"forcecharm" : false,
"life" : 0,
"unitcount" : 1,
"relationcount" : 1,
"minunits" : 0,
"txn-revno" : NumberLong(5),
"metric-credentials" : BinData(0,""),
"exposed" : false,
"scale" : 0,
"passwordhash" : "",
"txn-queue" : [
"605b683f4407403a33b31ad6_e51cce2f"
]
}
Updates for: Many a man has fallen in love with a girl in a light so dim he would not have chosen a suit by it. -- Maurice Chevalier
done P02
you're not worth my love if you only love to hate me <3 not shy not me :>
Tell Anna I don't want to be friends :-O
I keep getting stalked by this girl called Anna. She is at home by herself and feeling very alone. She has pictures to prove it and she really, really, REALLY, wants me to click on the link to see them! In fact, she wants me to see them so desperately that she actually started emailing me from several domains at once! Now that's impressive! I'm sorry Anna, but I don't want to be friends.
- Add multiple malware domains
- Suddenly remember that Anna is a Latin form of the Greek: Ἄννα and the Hebrew name Hannah (Hebrew: חַנָּה Ḥannāh), meaning "favor" or "grace" or "beautiful"
add banana emoji and fruit reaction
sorry he's kinda ugly :(
Added important disambiguation to swarm mode (#10987)
- Added important disambiguation to swarm mode
This really needs to be added, I had no idea people gave up on docker/swarm because of a misunderstanding, but it's common enough we need to clarify it.
From Docker's public #swarm slack channel:
andrew grosser 4:45 PM
Hey @channel I am about to give a talk in San Francisco to a bunch of devops experts about swarm using my ingress and reverse proxy controller https://github.com/sfproductlabs/roo and one of the organizers said swarm was deprecated, is that so? It's so much easier than kubernetes, I can't imagine losing it.
sfproductlabs/roo
A zero config distributed edge-router & reverse-proxy (supporting multiple letsencrypt/https hosts). No dependencies.
Stars
40
Language
Go
<https://github.com/sfproductlabs/roo|sfproductlabs/roo>sfproductlabs/roo | Apr 9th | Added by GitHub
4:46
Is there something we don't know?
james_wells 4:48 PM
As of the most recent official Docker release, no Swarm is still officially part of Docker... They merely added native support for Kubernetes
andrew grosser 4:49 PM
:pray: Phew, is there an EOL?
4:49
Thanks @james_wells
4:50
I think they going to get the grenade launchers out if I can't answer these questions
james_wells 4:51 PM
Now that is a good question and my guess is that no, there is no plan to remove it, at least before Docker 3.
andrew grosser 4:52 PM
Amazing thx, I have a system that is a startups dream and is personally saving me more than 10x using swarm, so praying it stays
bmitch:docker: 4:53 PM
Classic container deployed swarm is deprecated (I believe). Swarm mode that's integrated into the engine is still being developed by Mirantis with no EOL set.
4:53
So if someone says swarm is deprecated, make sure to ask "which swarm" they are referring to.
andrew grosser 4:54 PM
Ok thanks @bmitch
4:54
Think that's a brand thing we'll need to help change
james_wells 4:56 PM
@bmitch I am not sure I understand what you are sayin there. Could you please explain the differences
bmitch:docker: 4:56 PM
See the disambiguation section: https://hub.docker.com/r/dockerswarm/swarm
james_wells 4:57 PM
Excellent. Thank you sir
andrew grosser 5:02 PM
Thanks
bmitch:docker: 5:02 PM
See also this link where they are getting ready to archive the standalone swarm, aka classic swarm. https://github.com/docker/classicswarm/issues/2985#issuecomment-640486361
justincormackjustincormack
Comment on #2985 Why have all issues been closed?
The vast majority of issues were from 5 years ago when it was being actively developed, and the recent ones were all mistakes for swarmkit, other than some issues I resolved. Many were issues in components or Moby or other software and may be resolved. It is GitHubs (reasonable) recommendation that you close issues and PRs before archiving a repository so that people know they are not being worked on, and I was also looking to see if anyone came forward to say that they were still working on things or, indeed, actively using Swarm Classic.
<https://github.com/docker/classicswarm|docker/classicswarm>docker/classicswarm | Jun 8th | Added by GitHub
james_wells 5:08 PM
That is really unfortunate... Kubernetes is simply too expensive IMNSHO, Swarm is nice and lightweight.
andrew grosser 5:08 PM
Both the different swarms point to the same point in the documentation in the disambiguation @bmitch
bmitch:docker: 5:09 PM
Swarm mode, aka swarmkit is alive and well.
andrew grosser 5:10 PM
Whoa I can see why they were confused
bmitch:docker: 5:10 PM
If you type docker swarm init you are not running classic swarm
andrew grosser 5:11 PM
Can someone inside docker add this to the swarm docs page? I think it's important
5:12
I think something talking about 2014 was EOLd but this is still current and alive would help.
bmitch:docker: 5:12 PM
Docker themselves isn't maintaining it, that team went to Mirantis, so someone over there would need to submit the PR
andrew grosser 5:12 PM
OK, could I?
bmitch:docker: 5:13 PM
Docs are in GitHub
andrew grosser 5:13 PM
Thanks
-
Minor edit to the wording to clarify the diff
-
Minor update
Co-authored-by: Usha Mandya [email protected]
Reverts 3419, 3840, 3850, 3882, and 3890 (#4136)
PLEASE FOR THE LOVE OF GOD PING ME IF THIS MADE IT WORSE THAN BEFORE WE WILL ROLL BACK IMMEDIATELY GOD HAVE MERCY
Add files via upload
Oreilly - Linux Cookbook 2005.pdf This unique and valuable collection of tips, tools, and scripts provides clear, concise, hands-on solutions that can be applied to the challenges facing anyone running a network of Linux servers from small networks to large data centers in the practical and popular problem-solution-discussion O'Reilly cookbook format.The Linux Cookbook covers everything you'd expect: backups, new users, and the like. But it also covers the non-obvious information that is often ignored in other books the time-sinks and headaches that are a real part of an administrator's job, such as: dealing with odd kinds of devices that Linux historically hasn't supported well, building multi-boot systems, and handling things like video and audio.The knowledge needed to install, deploy, and maintain Linux is not easily found, and no Linux distribution gets it just right. Scattered information can be found in a pile of man pages, texinfo files, and source code comments, but the best source of information is the experts themselves who built up a working knowledge of managing Linux systems. This cookbook's proven techniques distill years of hard-won experience into practical cut-and-paste solutions to everyday Linux dilemmas.Use just one recipe from this varied collection of real-world solutions, and the hours of tedious trial-and-error saved will more than pay for the cost of the book. But those who prefer to learn hands-on will find that this cookbook not only solves immediate problems quickly, it also cuts right to the chase pointing out potential pitfalls and illustrating tested practices that can be applied to a myriad of other situations.Whether you're responsible for a small Linux system, a huge corporate system, or a mixed Linux/Windows/MacOS network, you'll find valuable, to-the-point, practical recipes for dealing with Linux systems everyday. The Linux Cookbook is more than a time-saver; it's a sanity saver.
this map has so many fucking issues holy shit (#4195)
aaaAAAAAAA
[HACK]: base: power: wakeup: create a dummy debugfs entry for trace_marker
ah shit you finally disabled debugfs only to see userspace scream at you for not having trace_marker this is the only driver which creates a debugfs entry which is essential for battery monitoring (see 1bdb13584fb7b5c6b7b741e4436a4dc4397df26e) adjust it's init function to create said dummy trace file inside tracing dir this will suppress the silly userspace errors
FINAL COMMIT
With 7 Models
Life is better now!
This mess was an interesting experience
Dont revert to the commit 2 steps before this, you'll enjoy the mess though.
i managed to write tarball installation routine lmao (that is also pink!). folks, turns out having experience really does help and with it bash — once being mysterious piece of shit — reveals itself as clunky, dumb, retardedly engineered piece of shit