10 interesting stories served every morning and every evening.
the atmosphere in the last week was kind of special. We experienced the feeling of the ﬁnal release being on the horizon many times. And we were shown that it isn’t the case time and time again. So it feels very special when it is actually becoming reality. We were trying to be especially careful with any last minute changes to make sure that we don’t introduce major bugs into our precious 1.0 release. The image of all the players having the game crash on some simple stupid bug is horrifying.
People thanked us on many occasions for the hard work we do. It helped lift our mood in many of the desperate moments, when bugs and problems were piling up and we didn’t see the end of the tunnel. We don’t say it often enough, but the support from your side has been incredibly helpful throughout the years.
We thank all who helped us to save the game before it could even start by supporting the IndieGoGo campaign back in 2013.
We are grateful for all of the 18,855 bug reports. They were invaluable feedback that helped us reach our level of game stability.
We value almost all of the feedback to our FFF and game releases. A lot of game improvements came out of it.
We appreciate the work and creativity that went into creating the 5,603 mods. It certainly extends the potential for a lot of people, and the ideas became a great inspiration for us.
All the online videos, articles and streams were immensely helpful to spread the word.
We thank all who helped with the Crowdin translations, allowing the game to be played in a lot of different languages without us having to manage it directly.
We are grateful that people spontaneously helped to manage the Wiki and created some great tools, like calculators, cheat sheets or blueprint databases.
We value the effort put into organising events, like fMMO, Clustorio etc.
We appreciate that our community is very civilised, and people who contribute are generally nice to each other, and keeping the criticism on the constructive side.
And, lastly, we would like to thank all of you who bought the game, and allowed all of this to happen.
It took us 8.5 years. It has been an incredible ride and we have arrived at the destination!
Factorio is leaving early access. This opens the game up to all the players who just don’t play early access games, the same with reviewers who only cover ﬁnished games, which is very understandable.
For this special occasion, we created a launch trailer. It tries to capture the story of the development in 45 seconds.
Since the main Trailer is kind of timeless, we updated it to the 1.0 state of the game.
When we released pretty much all the content in 0.18, there was nothing left for 1.0 other than the formality of “it is complete”. The crash site, nuke, alien decoratives and polluted water are awesome, but not too impactful… As a result, we really wanted to add something to make the release special.
It is a vehicle that can be driven, or remotely controlled.
It can traverse obstacles and small bodies of water.
It has a built-in radar, and you can place blueprints in its vicinity.
It has an equipment grid, so it can build with construction robots and use combat equipment.
It has four rapid-ﬁring rocket launchers that can shoot automatically.
It can be researched very late in the game (all science packs except Space).
Multiple of them can be deployed at the same time, but each requires its own linked controller.
This all means it can be used as a tank upgrade, a less automated version of artillery, or a builder/repairer. We look forward to seeing what other uses you can invent.
We haven’t added it earlier as we saw it just as a gimmick without much contribution to the gameplay mechanics. This changed rather recently, when we had the idea of the remote control combined with the equipment grid. So we decided to extend our already crazy todo list, and add it as a last minute bonus.
We were doing the best we could, to ﬁx all the relevant bugs and issues for the 1.0 release, but we just couldn’t do everything. So we had to prioritise just the more critical stuff. We would still like to address all of the remaining issues as there are currently around 150 bugs on the forums and around 80 internal tasks to be solved. The plan is to eventually go through all of them, and decide on how to resolve each one.
A good example is, that we have a “continue” button, but it just ignores multiplayer. You press continue automatically just to ﬁnd out, that you are building alone for half an hour. It is my (kovarex) personal story actually.
This means, that 1.1 is going to just focus on ﬁlling the most obvious gaps in our existing feature set, not on adding some new major content.
When we started with the Friday facts, it was at a time when we worked a lot, but if there wasn’t any release for a while, people were starting to ask whether the game is still being worked on. So this was our ﬁrst motivation. Eventually we learned many additional advantages of the blog, other than it being just a dead mans switch.
It established the communication channel between us and the community.
It started to be an internal every-week milestone to get something into a presentable form.
In some cases it even motivated us to add a cool last minute feature to make the topic feel more complete. (This is how the undo and copy-paste feature was created for example)
It became a great archive of the evolution of the game throughout the years. Opening old posts is like reading our own diary.
It became an every Friday habit for us and some of our players too, but we believe now is the right time to stop. There will hardly be a better moment to do so. It should be very understandable that we need a break, and we also need the freedom to think about the long term without the obligation to cut it into small chunks for FFF.
Since you can’t expect weekly posts from now on, we wanted a way for you to be notiﬁed once we have something special to say. Feel free to give us your email address so we can let you know.
For now please enjoy the game, and we’ll be back!
Discuss on our forums
Discuss on Reddit
This process is automatic. Your browser will redirect to your requested content shortly.
Please allow up to 5 seconds…
Servo is a prototype web browser engine written in the
Rust language. It is currently developed on 64-bit macOS, 64-bit Linux, 64-bit Windows, and Android.
Servo welcomes contribution from everyone. See
CONTRIBUTING.md and HACKING_QUICKSTART.md
for help getting started.
Visit the Servo Project page for news and guides.
Building servo requires rustup, version 1.8.0 or more recent. If you have an older version, run rustup self update.
To install on Windows, download and run rustup-init.exe
then follow the onscreen instructions.
To install on other systems, run:
curl https://sh.rustup.rs -sSf | sh
This will also download the current stable version of Rust, which Servo won’t use. To skip that step, run instead:
curl https://sh.rustup.rs -sSf | sh -s — –default-toolchain none
See also Other installation methods
Xcode version 10.2 or above is recommended.
NOTE: run these steps after you’ve cloned the project locally.
brew bundle install –ﬁle=etc/taskcluster/macos/Brewﬁle
brew bundle install –ﬁle=etc/taskcluster/macos/Brewﬁle-build
pip install virtualenv
sudo apt install python-virtualenv python-pip
If ./mach bootstrap doesn’t work, ﬁle a bug, and, run the commands below:
sudo apt install git curl autoconf libx11-dev libfreetype6-dev libgl1-mesa-dri \
libglib2.0-dev xorg-dev gperf g++ build-essential cmake libssl-dev \
liblzma-dev libxmu6 libxmu-dev \
libxcb-render0-dev libxcb-shape0-dev libxcb-xﬁxes0-dev \
libgles2-mesa-dev libegl1-mesa-dev libdbus-1-dev libharfbuzz-dev ccache \
clang libunwind-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev \
libgstreamer-plugins-bad1.0-dev autoconf2.13 llvm-dev
Additionally, you’ll need a local copy of GStreamer with a version later than 16.2. You can place it in support/linux/gstreamer/gst, or run ./mach bootstrap-gstreamer to set it up. On Ubuntu 20.04LTS, you can use the system GStreamer if you install the necessary packages:
sudo apt install gstreamer1.0-nice gstreamer1.0-plugins-bad
If you are using Ubuntu 16.04 or Linux Mint 18.* run export HARFBUZZ_SYS_NO_PKG_CONFIG=1 before building to avoid an error with harfbuzz.
If you get an undeﬁned symbol error on gst_player_get_conﬁg try removing gir1.2-gst-plugins-bad-1.0 and all old versions of clang, see #22016
sudo dnf install python3 python3-virtualenv python3-pip python3-devel
python3 ./mach bootstrap
If python3 ./mach bootstrap doesn’t work, ﬁle a bug, and, run the commands below:
sudo dnf install curl libtool gcc-c++ libXi-devel libunwind-devel \
freetype-devel mesa-libGL-devel mesa-libEGL-devel glib2-devel libX11-devel \
libXrandr-devel gperf fontconﬁg-devel cabextract ttmkfdir expat-devel \
rpm-build openssl-devel cmake libX11-devel libXcursor-devel \
libXmu-devel dbus-devel ncurses-devel harfbuzz-devel \
ccache clang clang-libs python3-devel gstreamer1-devel \
gstreamer1-plugins-base-devel gstreamer1-plugins-bad-free-devel autoconf213
sudo yum install python-virtualenv python-pip
If ./mach bootstrap doesn’t work, ﬁle a bug, and, run the commands below:
sudo yum install curl libtool gcc-c++ libXi-devel freetype-devel \
mesa-libGL-devel mesa-libEGL-devel glib2-devel libX11-devel libXrandr-devel \
gperf fontconﬁg-devel cabextract ttmkfdir python expat-devel rpm-build \
openssl-devel cmake3 libXcursor-devel libXmu-devel \
dbus-devel ncurses-devel python34 harfbuzz-devel \
ccache clang clang-libs llvm-toolset-7
scl enable devtoolset-7 llvm-toolset-7 bash
with the following environmental variables set:
sudo zypper install libX11-devel libexpat-devel Mesa-libEGL-devel Mesa-libGL-devel cabextract cmake \
dbus-1-devel fontconﬁg-devel freetype-devel gcc-c++ git glib2-devel gperf \
harfbuzz-devel libXcursor-devel libXi-devel libXmu-devel libXrandr-devel libopenssl-devel \
python-pip python-virtualenv rpm-build ccache llvm-clang libclang autoconf213 gstreamer-devel \
sudo pacman -S –needed base-devel git python2 python2-virtualenv python2-pip mesa cmake libxmu \
pkg-conﬁg ttf-ﬁra-sans harfbuzz ccache llvm clang autoconf2.13 gstreamer gstreamer-vaapi
sudo emerge net-misc/curl \
media-libs/freetype media-libs/mesa dev-util/gperf \
dev-python/virtualenv dev-python/pip dev-libs/openssl \
media-libs/harfbuzz dev-util/ccache sys-libs/libunwind \
x11-libs/libXmu x11-base/xorg-server sys-devel/clang \
media-libs/gstreamer media-libs/gst-plugins-bad media-libs/gst-plugins-base
With the following environment variable set:
export LIBCLANG_PATH=$(llvm-conﬁg –preﬁx)/lib64
Install Python 2.7 for Windows (https://www.python.org/downloads/release/python-2716/). The Windows x86-64 MSI installer is ﬁne. This is required for the build system execution and many dependencies.
You should change the installation to install the “Add python.exe to Path” feature.
You will also need to set the PYTHON2 environment variable, e.g., to ‘C:\Python27\python.exe’ by doing:
setx PYTHON2 “C:\Python27\python.exe” /m
You will also need to set the PYTHON3 environment variable, e.g., to ‘C:\Python37\python.exe’ by doing:
setx PYTHON3 “C:\Python37\python.exe” /m
The /m will set it system-wide for all future command windows.
In a normal Windows Shell (cmd.exe or “Command Prompt” from the start menu), do:
pip install virtualenv
If this does not work, you may need to reboot for the changed PATH settings (by the python installer) to take effect.
Install the most recent GStreamer MSVC packages. You need to download the two .msi ﬁles for your platform from the GStreamer website and install them. The currently recommended version is 1.16.0. i.e.:
Note that the MinGW binaries will not work, so make sure that you install the MSVC the ones.
Note that you should ensure that all components are installed from gstreamer, as we require many of the optional libraries that are not installed by default.
Install Git for Windows (https://git-scm.com/download/win). DO allow it to add git.exe to the PATH (default settings for the installer are ﬁne).
Install Visual Studio Community 2017 (https://www.visualstudio.com/vs/community/). You MUST add “Visual C++” to the list of installed components as well as the “Windows Universal C runtime.” They are not on by default. Visual Studio 2017 MUST installed to the default location or mach.bat will not ﬁnd it.
Note that version is hard to download online and is easier to install via Chocolatey with:
choco install -y visualstudio2017community –package-parameters=“‘–add Microsoft.VisualStudio.Component.Git’”
Update-SessionEnvironment #refreshing env due to Git install
#–- UWP Workload and installing Windows Template Studio –-
choco install -y visualstudio2017-workload-nativedesktop
You may experience much faster builds on Windows by following these steps. (Related Rust issue: https://github.com/rust-lang/rust/issues/37543)
Run the installer and choose to add LLVM to the system PATH.
Add the following to your Cargo conﬁg (Found at %USERPROFILE%\.cargo\conﬁg). You may need to change the triple to match your environment.
linker = “lld-link.exe”
If you encountered errors with the environment above, do the following for a workaround:
If you have troubles with x64 type prompt as mach.bat set by default:
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.
Multiple sources have reported that the disastrous explosion at Port of Beirut was sparked by hot work at a warehouse where ofﬁcials had stored 2,750 tonnes of conﬁscated ammonium nitrate and a cache of ﬁreworks. In a new report, senior ofﬁcials provided Reuters with additional details: early this year they had learned that one of the warehouse’s doors was broken, raising the risk that a malicious actor could steal dangerous explosives. The port’s welding contractors set off the cache while trying to repair the door to protect the cache.
According to the report, the security investigation that set this chain in motion began in January after the broken door and a large hole in the warehouse’s wall were discovered. On June 4 - six months later - state security forces ordered the port to guard the warehouse and make appropriate repairs. On August 4 - two months after the order - the port sent a team of Syrian workers to ﬁx the warehouse. Sparks from their welding work ignited a supply of ﬁreworks, which had been stored next to the ammonium nitrate cache.
Reuters reports that the prime minister and the president of Lebanon were informed of the security lapses at the site.
On Monday, Lebanese prime minister Hassan Diab tendered his resignation to Lebanon’s president, Michel Aoun, who accepted his resignation and immediately appointed him caretaker prime minister. The rest of the current government’s ministers are also expected to continue to serve in a caretaker capacity, including three who resigned in protest over the past several days.
“I declare today the resignation of this government. May God protect Lebanon,” Diab said in a televised statement. “This disaster is the result of chronic corruption. The corruption network is bigger than the state.”
Protests calling for the replacement of the government continued after Diab’s resignation speech. The confrontation has been marked by violence: more than 700 people have been injured in clashes with state security forces over the course of the past week, including many who have been hit by birdshot pellets and less-than-lethal munitions.
Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
will be resized to 93x93 pixels
will be blurred and dithered just as the preview
you can clip the preview
NOTE: You need to enter text or your QR might not scan
NOTE: Not supported (yet)
This VCard is stored on this server
The QR will have a http:// link to the VCard
When scanning the QR you will need internet access to download the VCard
!! Please be patient, the generator needs at least 20 seconds
Colour drawing (large areas of same colour)
Colour picture (a lot of colours/shades)
This service is available in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
Yesterday or so a new initiative I Love MDN was unveiled. People can show their appreciation for the MDN staff and volunteers by leaving a comment.
I have a difﬁcult message about this initiative. For almost a day I’ve been trying to ﬁnd a way to bring that message across in an understanding, uplifting sort of way, but I failed.
Before I continue I’d like to remind you that I ran the precursor to MDN, all by myself, for 15 years, mostly for free. I was a community volunteer. I know exactly what goes into that, and what you get back from it. I also burned out on it, and that probably colours my judgement.
So here is my message, warts and all.
I ﬁnd I Love MDN demeaning to technical writers. It reminds me of breaking into spontaneous applause for our courageous health workers instead of funding them properly so they can do their jobs.
It pretends techincal writing is something that can be done by ‘the community’, ie. random people, instead of being a job that requires very specialised skills. If you deny these skills exist by pretending anyone can do it, you’re demeaning the people who have actually taken the time and trouble to build up those skills.
In addition, I see the I Love MDN initiative as an example of the cult of the free, of everything that’s wrong with the web development community today. The co-signers unthinkingly assume they are entitled to free content.
Unthinking is the keyword here. I do not doubt that the intentions of the organisers and co-signers are good, and that they did not mean to bring across any of the nasty things I said above and will say below. They just want to show MDN contributors that their work is being valued.
Thatr’s nice. But it’s not enough. Far from it.
Take a look here. It is my old browser compatibility site after four to six years of lying fallow. Would you use this as a resource for your daily work? There are still some useful bits, but it’s clear that the majority of these pages are sadly outdated.
That will be MDN’s fate under a volunteer-only regime.
What we need is money to retain a few core technical writers permanently. I Love MDN ignores that angle completely.
Did you sign I Love MDN? Great! Are you willing to pay 50-100 euros/dollars per year to keep MDN aﬂoat? If not, this is all about making you feel better, not the technical writers. You’re part of the problem, not the solution.
MDN Web Docs is the life blood, the home, the source of truth for millions of web developers everyday. […] As a community of developers we have access to all of this information for free ♥️
We get everything for free hurray hurray, also, too, community community community, and, hey! with that statement out of the way we’re done. Now let’s congratulate ourselves with our profound profundity and dance the glad dance of joy. Unicorn-shitting rainbows will be ours forever!
I Love MDN hinges on the expectation on the part of web developers that this sort of information ought to come for free — the expectation we’re entitled to this sort of free ride.
This is all made possible by a passionate community, inspirational technical writers, and a small, but determined team of developers.
Hogwash. The passionate community has nothing to do with anything, unless they’re willing to pay. A profoundly unscientiﬁc poll indicates that only about two-thirds of my responding followers are willing to do so. The rest, apparently, is too passionate to pay. It’s just along for the free ride. That isn’t very comforting.
Rachel Andrew puts it better than I can:
The number of people who have told me that MDN is a wiki, therefore the community will keep it up to date tells me two things. People do not get the value of professional tech writers. Folk are incredibly optimistic about what “the community” will do for free.
So you once wrote an MDN page. Great! Thanks!
But will you do the boring but necessary browser testing to ﬁgure out if what you’re describing is always true, or just most of the time? And will you repeat that testing once new versions have come out? Will you go through related pages and update any references that need to be updated? Will you follow advances in what you described and update the page? If someone points out an error six months from now, will you return to the page to revise it and do the necessary research?
If the answer to any of these questions is No you did a quarter of your job and then walked away. Not very useful.
And if the answer to all of these questions is Yes, hey, great, you’ve got what it takes! You’re really into technical writing! We need you! Now, quick, tell me, how long will you keep it up without any form of payment? Quite a while, you say? Great! Try beating my record of 15 years.
The problem with expecting volunteers to do this sort of work is that they burn out. Been there, done that. And what happens when all volunteers burn out?
Yes, new volunteers will likely step up. But they have to be introduced to the documentation system, not only the techincal bits, but also the editorial requirements. Their ﬁrst contributions will have to be checked for factual errors and stylistic problems, for proper linking to related pages, for enough browser compatibility information. Who’s going to do that? Also volunteers? But they just burned out.
It doesn’t work in the long run.
What ought to happen is MDN (or its successor) securing the funding to retain a few core technical writers on a permanent basis. Without that, it’s doomed to fail.
Now there are two ways of securing funding. The ﬁrst one is appealing to big companies, particularly browser vendors. I can see Google, Microsoft, and Samsung chipping in a bit, maybe even quite a lot, to keep MDN running. (Apple won’t, of course. They’re on their own cloud.) This could work, especially in the short run.
But will we be well served by that in the long run? You might have noticed that all companies I named use a Chromium-based browser. What about Firefox? Or WebKit?
I have no doubt that the Chrome, Edge, and Samsung Internet developer relations teams are totally serious about keeping other browsers on board and will not bend MDN new-style to their own browsers in any way. They’ve shown their commitment to browser diversity time and again.
What I doubt is that the ﬁnal decision rests with them. Once MDN new-style funded by the browser vendors has been running for a while, managers will poke their heads around the corner to ask what we, as in Google, Microsoft, or Samsung, get in return for all the money we’re spending. More attention for our browser, that’s what. Make it so!
That’s why I prefer the second option in the long run: funding by the web community itself. Create an independent entity like Fronteers, but then international, get members to pay 50-100 euros/dollars per year, and use that money to fund MDN or its successor.
Now this is a lot of work. But I still feel it needs to be done.
But who will do it? Volunteers? We’ll run into the same problem that I sketched above, just one step removed. I brieﬂy considered starting such an initiative myself, but I found that I am unwilling to do it for free.
And I know exactly what it takes. I founded Fronteers for free, and it took me half a year of mind-numbing work, including fending off random community members who also had an opinion. Even though others stepped up and helped, my ﬁrst burn-out was mostly caused by Fronteers’s founding, and I am unwilling to do it all over again for free.
So there we are. On balance, it’s more likely we go with the big-company solution that will work in the short run but will give problems in the long run.
Unless the web development community stops expecting a free ride, and starts to pay up. Initiatives such as I Love MDN don’t give me a lot of hope, though.
Previous entry: The cult of the free must die
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
The University has cancelled nearly all in-person instruction for the upcoming fall quarter and is suspending its plans to provide on-campus housing to frosh, sophomores and incoming transfer students, according to a Thursday announcement by President Marc Tessier-Lavigne.
“The recent state guidance for higher education to curtail the spread of COVID-19 … prohibits most indoor classes while our county is still on the ‘watch list,’ and it includes other restrictions on activities that would make for a very limiting on-campus undergraduate experience this fall,” Provost Persis Drell wrote in an email to faculty.
The University will invite graduate and professional students back as planned, along with the approximately 800 undergraduates from across four class years whose petitions to return to campus have been granted.
The new plan will allow frosh and sophomores to live on campus in winter quarter, and juniors and seniors in spring quarter, if conditions allow.
The University has revoked the positions for a majority of its 275 on-campus student staff except for those assigned to Escondido Village Graduate Residences A (EVGR-A) and Mirrielees, according to an email from Assistant Vice Provost for Residential Education Cheryl Brown. There may be RA opportunities for the limited number of students approved for on-campus housing.
There will be no virtual student stafﬁng roles due to “budgetary constraints and equity issues.”
Student staff “will be invited to serve in their on-campus student staff roles when the houses reopen,” she added. “We hope to honor RA, ETA, and ATA appointments for up to three quarters.”
The decision to roll back the return-to-campus plan comes two days after the Pac-12 postponed fall sports due to concerns over COVID-19, and it also follows decisions by other institutions, most recently the University of Pennsylvania, to do the same.
Despite clear signaling from health professionals that the COVID-19 pandemic wouldn’t see an end in time for fall classes and after a series of delays in making a decision, Stanford was hopeful in inviting back half its undergraduate class each quarter while running a majority of its courses remotely. More delays and a shaky warning at the end of July all but pointed to the eventual decision to cancel on-site aspects of fall quarter.
For weeks prior, students had expressed concerns about the University’s decision to keep its housing plans in place, saying that it would endanger the health of students and workers and disproportionately affect low-income and housing insecure students who may not have the option of staying home.
The University’s decisions in response to challenges presented by COVID-19 will continue to take its toll on workers. Two weeks ago, Stanford announced that it would permanently lay off 208 workers and furlough 30 more due to “budgetary challenges.” Tessier-Lavigne said in an Aug. 3 virtual meeting that if students were not invited back in the fall, further layoffs may be necessary.
The ﬁrst day of online classes is still scheduled for Sept. 14. The Faculty Senate recently passed a measure ensuring that all courses offered under a letter grading basis would also include optional credit/no credit (CR/NC) grading to accommodate uncertainty in the upcoming academic year.