I got the Trial version of CityEngine for a Uni project a couple years ago. It was very crashy, almost unusable. Not sure if that was a problem with the trial or it also happened in the full version, though.
My question is, why KEEP it at all? It's old, flawed, and has been patched up a lot of times to make it keep up. It has run it's course. What's wrong with retiring old things in favour of newer ones?
I'd like to point you are the rest of the world outside your narrow version of the world that's the US.
Out here, we have two kinds of countries: those that don't care to see guns everywhere, and those that are in open war. For most of us, the world DOES work that way. We don't live with the fear that someone will randomly shoot us, because if anyone does shoot, it's NOT random. Said person has a purpose, a goal. And people with a goal tend not to care about little people like me who just live their lives without bothering anyone. That is, as long as we are not in a war.
Imagine a future where having access to your storage space, and being able to see the raw contents of your data is something of the distant past. When someone finds some old device, labelled as containing music, that seems to have used a PHYSICAL connection to a computer. This person tries to find the means to recover that music, but realizes that the only people with such old computers charge a huge lot of money to extract them from the device, and make them available on the new-internet, assuming they are allowed to, because the corporations that were elected to run the government have very strict rules on what data can be made available, to who, and at what price.
If the general population doesn't have have guns, then someone who DOES carry a gun, and isn't in a police/guard uniform, must be evil. It makes things much simpler.
The other big change is the merging of XMir handling in the xf86-video-intel driver. When using XMir for running X11/X.Org applications atop a Mir display server, modified DDX drivers are still required. These modifications are now present in the xf86-video-intel driver by default rather than Canonical carrying the work as out-of-tree patches.
Also, it's much harder to find efficient PSUs at low ratings. I checked at some point, and a 800W PSU at 20% usage was more efficient than a 450W PSU at 50% usage, so you have to keep that in mind too.
A power supply is its most efficient at around 50% usage. So if you take the time to measure the average power usage of your system
you can buy a PSU that's approximately 2x the average, or 25% more than the peak, whichever is higher.
My system takes around 100w idle, or 250w on load, with peaks never going over 300w. so a 400w PSU would be more than enough for my usage patterns. Yet I have a 850w PSU simply because it was the one PSU they had in stock in the store I buy from, when the old one broke. The old one was 650W, and it was also more than enough for my needs.
... Microsoft would now say that they may be spending even more in support after the change.
Has anyone given actual numbers on that, yet? Anyone who has fully switched away from Microsoft Office and, after a few years, has numbers showing they spent less overall?
The project is split in two parts: a shared library which is loaded into your Linux browser and a pluginloader which is executed in Wine. The shared library offers the Netscape Plugin API (NPAPI) to the browsers and acts like all other plugins, except the fact that it does not provide the API functions directly. When the library is loaded by the browsers it starts the pluginloader in Wine and sends all API calls to the plugin through a pipe. The loader will listen for this calls and send them to the Silverlight plugin. All handles, interfaces and objects which are only available at one side are recreated as fake objects on the other side, so that we can capture all calls and redirect them through the pipe. The real handles are replaced by fake 64 bit IDs during the transmission, which allows us to load 32 bit plugins into 64 bit browsers and vice versa without having to pay attention at the size of the real handles. The only real difference in the API between Linux and Windows is the handling of drawing and input events, which requires additional code inside the pluginloader.
Yes, it is. Stupid summary making it sound more complicated than it really is.
You CAN write to a cell without first erasing it: if it was in its reset state, either because it hadn't been written before, or because the contents were TRIMmed or explicitly erased. With TRIM support, that means any time you write to a previously unused physical sector. Overwriting data DOES require an erase, though.
Not quite: in any practical usage, there's a lot of sectors that are only written once, and a few sectors that are written a lot more often. As an example: System files, and the TEMP folder, respectively. With wear leveling, the controller is free to swap them around, so that all the sectors are used more.
Of course, that sector rotation could result in the TOTAL number of writes/erases going up, but without wear leveling, all the sectors corresponding to the often-written files (TEMP, logs, pagefile/swap,...) would die out quite quickly.
Flash memory has a special transistor with a gate that's disconnected from the circuit. This gate can be loaded with electrons by sending them at a high enough voltage, or "sucked" empty by quantum tunneling.
I don't know exactly which is write and which is erase but: the write operation is less costly, but it can only turn bits off but not back on (or the other way around). When you need to reset the bits, so that they can be turned back off, you have to erase the sectors. The erase operation is more costly, and wears down the "floating gate" a lot quicker. Since it's more costly, it's done on a larger group of sectors at the same time. This means that you can reset a whole group, but then only write a piece of it. Here's where the famous TRIM comes to help: without TRIM, the flash controller doesn't know which sectors of an erase group are still used, so when the OS asks for a sector write that requires an erase operation, it has to read all of the sectors, erase, and then write all of them. With TRIM, it can ignore the sectors that are marked as empty.
The reason why erase cycles are limited, is because in those "inject"/"vacuum" cycles, some electrons get stuck inside the gate, and the smaller the gates get, the quicker they fill up.
Read cycles? many millions. Write cycles? not so many, but a lot. ERASE cycles? around the 10k order of magnitude, for the latest generation TLC. And it will get smaller as they shrink the capacity of the floating gates (electrons get stuck there, and it fills quicker).
Slashdot Mirror
I got the Trial version of CityEngine for a Uni project a couple years ago. It was very crashy, almost unusable. Not sure if that was a problem with the trial or it also happened in the full version, though.
... except this one also takes the chance to express a subjective opinion on a movie that I personally liked enough.
My question is, why KEEP it at all? It's old, flawed, and has been patched up a lot of times to make it keep up. It has run it's course. What's wrong with retiring old things in favour of newer ones?
I'd like to point you are the rest of the world outside your narrow version of the world that's the US.
Out here, we have two kinds of countries: those that don't care to see guns everywhere, and those that are in open war. For most of us, the world DOES work that way. We don't live with the fear that someone will randomly shoot us, because if anyone does shoot, it's NOT random. Said person has a purpose, a goal. And people with a goal tend not to care about little people like me who just live their lives without bothering anyone. That is, as long as we are not in a war.
Imagine a future where having access to your storage space, and being able to see the raw contents of your data is something of the distant past. When someone finds some old device, labelled as containing music, that seems to have used a PHYSICAL connection to a computer. This person tries to find the means to recover that music, but realizes that the only people with such old computers charge a huge lot of money to extract them from the device, and make them available on the new-internet, assuming they are allowed to, because the corporations that were elected to run the government have very strict rules on what data can be made available, to who, and at what price.
If the general population doesn't have have guns, then someone who DOES carry a gun, and isn't in a police/guard uniform, must be evil. It makes things much simpler.
Will be a header code that says "do wiretap me, I have something interesting to hide!"
The other big change is the merging of XMir handling in the xf86-video-intel driver. When using XMir for running X11/X.Org applications atop a Mir display server, modified DDX drivers are still required. These modifications are now present in the xf86-video-intel driver by default rather than Canonical carrying the work as out-of-tree patches.
That seems to be their goal and intention. They only lack their own Steve Jobs as the brand's face.
Also, it's much harder to find efficient PSUs at low ratings. I checked at some point, and a 800W PSU at 20% usage was more efficient than a 450W PSU at 50% usage, so you have to keep that in mind too.
A power supply is its most efficient at around 50% usage. So if you take the time to measure the average power usage of your system you can buy a PSU that's approximately 2x the average, or 25% more than the peak, whichever is higher.
My system takes around 100w idle, or 250w on load, with peaks never going over 300w. so a 400w PSU would be more than enough for my usage patterns. Yet I have a 850w PSU simply because it was the one PSU they had in stock in the store I buy from, when the old one broke. The old one was 650W, and it was also more than enough for my needs.
Firefox has has a F*ing "Recently Closed Tabs" submenu since like Firefox 3?
HISTORY -> RECENTLY CLOSED TABS
If you don't show the menubar, I'm sure it's also there in the "one" button.
It even has more than one closed tab! Do you not use Firefox?
... Microsoft would now say that they may be spending even more in support after the change.
Has anyone given actual numbers on that, yet? Anyone who has fully switched away from Microsoft Office and, after a few years, has numbers showing they spent less overall?
... in spain they tax us extra for renewable energy, because otherwise it would be "unfair" to the industry...
Democracy is all about choosing who, and how, screws you over, so that the country can function, and the politicians can get rich.
Another one of those articles with question-titles that can be answered with a simple "No."?
The project is split in two parts: a shared library which is loaded into your Linux browser and a pluginloader which is executed in Wine. The shared library offers the Netscape Plugin API (NPAPI) to the browsers and acts like all other plugins, except the fact that it does not provide the API functions directly. When the library is loaded by the browsers it starts the pluginloader in Wine and sends all API calls to the plugin through a pipe. The loader will listen for this calls and send them to the Silverlight plugin. All handles, interfaces and objects which are only available at one side are recreated as fake objects on the other side, so that we can capture all calls and redirect them through the pipe. The real handles are replaced by fake 64 bit IDs during the transmission, which allows us to load 32 bit plugins into 64 bit browsers and vice versa without having to pay attention at the size of the real handles. The only real difference in the API between Linux and Windows is the handling of drawing and input events, which requires additional code inside the pluginloader.
Yes, it is. Stupid summary making it sound more complicated than it really is.
... make a netscape plugin, that loads windows netscape plugins? Sortof like plugin-host.exe Firefox uses? Or is it like that already?
You CAN write to a cell without first erasing it: if it was in its reset state, either because it hadn't been written before, or because the contents were TRIMmed or explicitly erased. With TRIM support, that means any time you write to a previously unused physical sector. Overwriting data DOES require an erase, though.
Not quite: in any practical usage, there's a lot of sectors that are only written once, and a few sectors that are written a lot more often. As an example: System files, and the TEMP folder, respectively. With wear leveling, the controller is free to swap them around, so that all the sectors are used more.
Of course, that sector rotation could result in the TOTAL number of writes/erases going up, but without wear leveling, all the sectors corresponding to the often-written files (TEMP, logs, pagefile/swap, ...) would die out quite quickly.
It's a bit like this:
Flash memory has a special transistor with a gate that's disconnected from the circuit. This gate can be loaded with electrons by sending them at a high enough voltage, or "sucked" empty by quantum tunneling.
I don't know exactly which is write and which is erase but: the write operation is less costly, but it can only turn bits off but not back on (or the other way around). When you need to reset the bits, so that they can be turned back off, you have to erase the sectors. The erase operation is more costly, and wears down the "floating gate" a lot quicker. Since it's more costly, it's done on a larger group of sectors at the same time. This means that you can reset a whole group, but then only write a piece of it. Here's where the famous TRIM comes to help: without TRIM, the flash controller doesn't know which sectors of an erase group are still used, so when the OS asks for a sector write that requires an erase operation, it has to read all of the sectors, erase, and then write all of them. With TRIM, it can ignore the sectors that are marked as empty.
The reason why erase cycles are limited, is because in those "inject"/"vacuum" cycles, some electrons get stuck inside the gate, and the smaller the gates get, the quicker they fill up.
With wear leveling?
Read cycles? many millions. Write cycles? not so many, but a lot. ERASE cycles? around the 10k order of magnitude, for the latest generation TLC. And it will get smaller as they shrink the capacity of the floating gates (electrons get stuck there, and it fills quicker).