We use bacula as a virtual tape backup solution for serveral servers, and I love it. We run a weekly full backup, followed by daily incremental snapshosts. That said, bacula has his shortcomings - it is no disaster recovery solution, it works on files and not at the filesystem level, so if you need to backup live data applications such as databases, either you create a dump first, which isn't practical to be made daily on big databases, or use a filesystem that supports snapshotting, back up from a snapshot and hope that the on-disk data is application-consistent. Also, because the file nature of the backup, a full backup job of a mail server can take several hours over a gigabit connection. For disaster recovery or full/incremental disk image backup of big datastores, there are a lot of (comercial) tools that provide continuous data protection - think versioned filesystem replication, with minimal impact to running systems.
Many PLC implementations are "open" in the sense that the protocol is open and documented. And while most hi.-power CNC machines aren't vulnerable to internet malware, that doesn't mean that ethernet/serial/can exposed PLC devices aren't. I don't work with PLCs since the late nineties, but I wouldn't be surprised if little to nothing has changed since.
As usually the disks are from the same provider, and often from the same lot, they share the same problems. If you're building a raid-1/10/3/4 setup, you should buy your disks (or disk sets) with the same specs, but from different manufacturers. Today it is easier said than done on server-grade stuff, but still possible on homemade builds.
The library dependence is irrelevant, because the libc gcc-compiled programs (including gcc-compiled gcc) use is completely independent from the libc used by the compiler used to bootstrap gcc.
The library dependence is not relevant, not only because you can build static binaries, but also because different compilers can/usually have completely different runtime implementations - the scanf() you program potentially uses is completely different if compiled with gcc and with a borland compiler.
To the n-th time: I did not propose to compare binaries produced by the bootstrap compilers. Is this now clear?
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables.
So, you have gcc source, you compile it with visual studio and c++ builder, and then use the generated compilers to re-compile gcc and then compare the resulting binaries. You build gcc on visual studio with depencies of microsoft libc equivalent runtime, and with c++ builder, with borland's library. Now you have two somewhat different versions of the same compiler, but with completely different code paths (since each vendor implements their version of the C runtime). Also, because visual studio and c++ builder are different compilers, significant optimization differences (and subsequent bugs) may occur between the two builded binaries. And you propose that it is expected that both versions of gcc generate exactly the same binary, without any difference or glitch? You do have a lot of faith in software.
I hardly consider having famine death levels worse than what we see today on some 3rd world countries as "worked out", but yeah, we're here today. And most theories indicate that "mankind" was an endangered specie for thousands of years, right to the point when they started working more and gathering less. But I agree that "survival of the fittest" is a really dumb argument for an 80 hour workweek.
If you are referring to GDP per capita comparison between countries, GDP isn't used to benchmark "productivity" per se, because it reflects the wage level of those countries. If Grece produced the same as Germany, they would have a lower GDP because of the lower salaries. Also, there are other factors that influence work hours - on service-oriented countries like Holland, it's easier to keep the same production level with less workhours than on countries heavily dependant of production industry, that usually demands a lot of work hours to produce results.
I guess you never worked the fields or farmed animals. Today is somewhat "easy" (compared to "back then", 100 years ago), but without mecanized tools, plague controlling chemicals, vaccines, soil analysis, and weather forecasts, you are in for a real treat - 7 days a week, from dusk till dawn, and even then you could get all your crops wiped out. One of the biggest wins of the 20th century is the quality of life provided by a mere 40-hour week.
I live in a country with strict labor laws and strong unions, and I can tell you that "being illegal" is not a big worry when you want to have your contract renewed. While I am self-employed and my "legal" problem is that >12h workdays are forbidden by law (sometimes I work on 20-30 hour cycles - by option), as an employer I would never hire a programmer that would indulge a 60h workweek, let alone 80h. From my experience, most professional programmers that spend that much time working are absolute crap because 1) usually they try to compensate lack of knowledge and talent with time 2) if they were that good they could have a job working much less, even if they spent the extra time on their personal projects.
To not repeat myself, I just refer you to my previous answer. [slashdot.org]
That clarifies the subject but you assume that compilers are perfect pieces of immutable software - they aren't. In the example you gave, it is expectable for gcc to have specific defines or makefile rules for each compiler, resulting on a different binary. Also, there is the problem of external dependencies - the libc implementation of Microsoft and Borland are different, even when the api is the same.
If you intend to compare the generated binaries, you of course use the same flags.
It is usual for different compilers to have different flags, that do not translate for the same optimization.
This is about comparing output from compiling the same source code.
The same source code (the same algorithm) can/will give you different binary results on different compilers, due to instruction alignment, code branching and optimization.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
Yeah, and when the results don't match, you don't know which version is tampered, so you're left at where you started.
You think it isn't very secure using a compiler as a service that is always running, but is it ok when you grab a binary of your open source compiler of preference from a mirror that is always running? And if you download it from source, do you check all the source code and related dependencies? and how about using a compiler on a operating system that is always running? (eg. a server?) How do you decide what is more trustable?
Two different compilers will obviously give you a different binary output. Even the same compiler will give you a different binary output, with different optimization flags or diffrerent architecture flags. Even with the same platform and optimization flags, a compiler might give you a different assembly for the same algorithm depending on specified alignments and/or instruction optimization. And yeah, your post also assumes that the cpu itself where you run the compilers isn't flawed or tampered in any way.
You know, COBOL still is the COBOL of the future... There is a ton of COBOL code being run as middleware for Java servlets. The COBOL OOP revamps are a niche (and thank god, because object oriented COBOL is like watching a terror movie), but there is a lot of investment on legacy conversion to Linux and.NET, and middleware interfacing and/or graphical revamps. You'll still have plenty of COBOL when the last VB6 application exits.
I doubt that Microsoft will put all the eggs on wone touchscreen basket, even considering the schedule release. Touchscreen interfaces are ok for some areas of work, but a big no for many others. While the consumer market is big for them, a big chunk of their income comes from "enterprise" products - Office and whatnot, and the server division. Given that many activities envolve real typing, I don't see touchscreen interfaces replacing keyboards and mouse on many activities.
While I don't agree with the seppuku bit, I do agree with you that current linux (and unix) DEs are a wasted opportunity. I love XFCE (as much I can love a X app), but KDE and Gnome should focus on user interaction on the base platform and not on eye candy. I've tried KDE4 and I've got the same dialogs that extended past the screen, the same out-of-place windows, the same bugs when resizing configuration windows loaded with different widgets, but on a slower pace than 3.5 - now a VESA framebuffer isn't enough to display interface bugs. On Gnome, I have the same kind of issues - big unresizable dialogs, that - on lower resolutions - hide the buttons, controls that aren't keyboard-friendly, etc. The last time I run Windows at 800x600 was not pleasant, but everything was available. I have a lot of customers that run windows at 800x600 or 1024x768 (older people tend to have worse eyesight), and at that resolutions pretty much every mainstream *nix DE is unusable.
You do know you can, on current versions of windows, replace the explorer desktop with another application, right? There's even a (rather cool and performant) blackbox port for windows.
The list is somewhat wrong. You should include NT4 Workstation (from 95-98 times), and XP 64 - a different desktop operating system, based on Windows 2003, and it rocked. And Windows 98 was absolute crap, 98 SE2 was somewhat tolerable, assuming you weren't using the network stack. By comparison, NT4 Workstation was rock-solid, but with smaller driver support and the need for huge amounts of ram.
While it is usual for cellphones to perform upscale of the photographed image, the big problem is sensor size. Given the same cells (MP), the bigger the sensor, the better the quality of the picture is. The smaller the cell size, the bigger the noise is in relation to the light captured. That's one of the reasons why the DSLR with 8MP will usually take a better picture than a 12MP compact camera.
It is also usual to put those "special" drivers on Linux upon install. Or to set some BIOS flags so Linux can actually boot. Server stuff uses a lot of custom hardware designed for a specific series, so it's not uncommon to have to provide extra drivers from the manufacturer upon install. Desktop hardware is a whole different game - the base schematic is usually the same, with some performance enhancements. I've yet to find a working desktop that has driver problems with windows.
I'm not saying I haven't had any problems with Windows drivers, just not with those bundled with Windows itself. I've had lots of issues (with several machines, different Windows versions and printer models) with HP - so much I've stopped buying any printer from HP, for example.
That's why drivers should be secondary to the OS code. In Vista and Windows 7, most drivers run in userspace, so if a driver crashes, it won't take down the whole operating system. The NT line of operating systems and its descendants use a hybrid kernel, while Linux is a traditional monolythic kernel. Linux is usually praised by its drivers "out of the box", but I've yet to see a windows machine crash with the supplied drivers, and I've had problems with some of the half-assed incomplete funcionality provided by linux kernel drivers.
While I agree that MS has treated C/C++ developers as second-class citizens, while trying to push the.NET dogfood (and aparently while rewriting all the Longhorn managed code back to c/c++),.NET isn't a failure in any way. Microsoft may be trying to swing it to the mobile market with little success, but on enterprise it's a whole different story.
AFAIK you can build a linux kernel without iso9660/joliet support and pack it on a distro. The fact that it is a "linux distro", it doesn't automatically mean than it can mount cd's out of the box.
PC-BSD does it, without breaking compatibility with the underlying FreeBSD. If you install a pbi package, it contains all the dependencies necessary to that given program and is installed on a separate dir. If you want to use the ports tree or install prebuilt packages, just use the default tools.
In fact, the problem you mention is probably one of the reasons I don't use linux on servers - on multi-purpose machines, I usually use FreeBSD with a bunch of jails, one for each kind of service (eg. database, mail filtering, mail server, www, etc), allowing me to upgrade each jail separalely without modifying other running services, at the cost of somewhat more expensive inter-jail comunication.
2-3KW Gasoline generators are dirt cheap in construction equipment stores, and you can run them several hundred meters away from the shooting site. If you need more power, you can rent professional generators. Also, there are a ton of car inverters (used for everything from caravans to powering laptops) on the 100W-1000W range. Over that, you'd need to connect it directly to the battery because of the required current.
As for silent options, you have portable sine inverters such as Explorer XT (350W, good enough for led lighting), and a whole range of ruggerized battery lights from Peli.
Many outdoor filmmakers are now using led-based lighting, so the 2000W mark is a bit high.
Slashdot Mirror
We use bacula as a virtual tape backup solution for serveral servers, and I love it. We run a weekly full backup, followed by daily incremental snapshosts. That said, bacula has his shortcomings - it is no disaster recovery solution, it works on files and not at the filesystem level, so if you need to backup live data applications such as databases, either you create a dump first, which isn't practical to be made daily on big databases, or use a filesystem that supports snapshotting, back up from a snapshot and hope that the on-disk data is application-consistent. Also, because the file nature of the backup, a full backup job of a mail server can take several hours over a gigabit connection. For disaster recovery or full/incremental disk image backup of big datastores, there are a lot of (comercial) tools that provide continuous data protection - think versioned filesystem replication, with minimal impact to running systems.
Many PLC implementations are "open" in the sense that the protocol is open and documented. And while most hi.-power CNC machines aren't vulnerable to internet malware, that doesn't mean that ethernet/serial/can exposed PLC devices aren't. I don't work with PLCs since the late nineties, but I wouldn't be surprised if little to nothing has changed since.
As usually the disks are from the same provider, and often from the same lot, they share the same problems. If you're building a raid-1/10/3/4 setup, you should buy your disks (or disk sets) with the same specs, but from different manufacturers. Today it is easier said than done on server-grade stuff, but still possible on homemade builds.
The library dependence is irrelevant, because the libc gcc-compiled programs (including gcc-compiled gcc) use is completely independent from the libc used by the compiler used to bootstrap gcc.
The library dependence is not relevant, not only because you can build static binaries, but also because different compilers can/usually have completely different runtime implementations - the scanf() you program potentially uses is completely different if compiled with gcc and with a borland compiler.
To the n-th time: I did not propose to compare binaries produced by the bootstrap compilers. Is this now clear?
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables.
So, you have gcc source, you compile it with visual studio and c++ builder, and then use the generated compilers to re-compile gcc and then compare the resulting binaries. You build gcc on visual studio with depencies of microsoft libc equivalent runtime, and with c++ builder, with borland's library. Now you have two somewhat different versions of the same compiler, but with completely different code paths (since each vendor implements their version of the C runtime). Also, because visual studio and c++ builder are different compilers, significant optimization differences (and subsequent bugs) may occur between the two builded binaries. And you propose that it is expected that both versions of gcc generate exactly the same binary, without any difference or glitch? You do have a lot of faith in software.
I hardly consider having famine death levels worse than what we see today on some 3rd world countries as "worked out", but yeah, we're here today. And most theories indicate that "mankind" was an endangered specie for thousands of years, right to the point when they started working more and gathering less. But I agree that "survival of the fittest" is a really dumb argument for an 80 hour workweek.
If you are referring to GDP per capita comparison between countries, GDP isn't used to benchmark "productivity" per se, because it reflects the wage level of those countries. If Grece produced the same as Germany, they would have a lower GDP because of the lower salaries. Also, there are other factors that influence work hours - on service-oriented countries like Holland, it's easier to keep the same production level with less workhours than on countries heavily dependant of production industry, that usually demands a lot of work hours to produce results.
I guess you never worked the fields or farmed animals. Today is somewhat "easy" (compared to "back then", 100 years ago), but without mecanized tools, plague controlling chemicals, vaccines, soil analysis, and weather forecasts, you are in for a real treat - 7 days a week, from dusk till dawn, and even then you could get all your crops wiped out. One of the biggest wins of the 20th century is the quality of life provided by a mere 40-hour week.
I live in a country with strict labor laws and strong unions, and I can tell you that "being illegal" is not a big worry when you want to have your contract renewed. While I am self-employed and my "legal" problem is that >12h workdays are forbidden by law (sometimes I work on 20-30 hour cycles - by option), as an employer I would never hire a programmer that would indulge a 60h workweek, let alone 80h. From my experience, most professional programmers that spend that much time working are absolute crap because 1) usually they try to compensate lack of knowledge and talent with time 2) if they were that good they could have a job working much less, even if they spent the extra time on their personal projects.
To not repeat myself, I just refer you to my previous answer. [slashdot.org]
That clarifies the subject but you assume that compilers are perfect pieces of immutable software - they aren't. In the example you gave, it is expectable for gcc to have specific defines or makefile rules for each compiler, resulting on a different binary. Also, there is the problem of external dependencies - the libc implementation of Microsoft and Borland are different, even when the api is the same.
If you intend to compare the generated binaries, you of course use the same flags.
It is usual for different compilers to have different flags, that do not translate for the same optimization.
This is about comparing output from compiling the same source code.
The same source code (the same algorithm) can/will give you different binary results on different compilers, due to instruction alignment, code branching and optimization.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
Yeah, and when the results don't match, you don't know which version is tampered, so you're left at where you started.
You think it isn't very secure using a compiler as a service that is always running, but is it ok when you grab a binary of your open source compiler of preference from a mirror that is always running? And if you download it from source, do you check all the source code and related dependencies? and how about using a compiler on a operating system that is always running? (eg. a server?) How do you decide what is more trustable?
Two different compilers will obviously give you a different binary output. Even the same compiler will give you a different binary output, with different optimization flags or diffrerent architecture flags. Even with the same platform and optimization flags, a compiler might give you a different assembly for the same algorithm depending on specified alignments and/or instruction optimization.
And yeah, your post also assumes that the cpu itself where you run the compilers isn't flawed or tampered in any way.
You know, COBOL still is the COBOL of the future... There is a ton of COBOL code being run as middleware for Java servlets. The COBOL OOP revamps are a niche (and thank god, because object oriented COBOL is like watching a terror movie), but there is a lot of investment on legacy conversion to Linux and .NET, and middleware interfacing and/or graphical revamps. You'll still have plenty of COBOL when the last VB6 application exits.
I doubt that Microsoft will put all the eggs on wone touchscreen basket, even considering the schedule release. Touchscreen interfaces are ok for some areas of work, but a big no for many others. While the consumer market is big for them, a big chunk of their income comes from "enterprise" products - Office and whatnot, and the server division. Given that many activities envolve real typing, I don't see touchscreen interfaces replacing keyboards and mouse on many activities.
While I don't agree with the seppuku bit, I do agree with you that current linux (and unix) DEs are a wasted opportunity. I love XFCE (as much I can love a X app), but KDE and Gnome should focus on user interaction on the base platform and not on eye candy. I've tried KDE4 and I've got the same dialogs that extended past the screen, the same out-of-place windows, the same bugs when resizing configuration windows loaded with different widgets, but on a slower pace than 3.5 - now a VESA framebuffer isn't enough to display interface bugs. On Gnome, I have the same kind of issues - big unresizable dialogs, that - on lower resolutions - hide the buttons, controls that aren't keyboard-friendly, etc. The last time I run Windows at 800x600 was not pleasant, but everything was available. I have a lot of customers that run windows at 800x600 or 1024x768 (older people tend to have worse eyesight), and at that resolutions pretty much every mainstream *nix DE is unusable.
You do know you can, on current versions of windows, replace the explorer desktop with another application, right? There's even a (rather cool and performant) blackbox port for windows.
The list is somewhat wrong. You should include NT4 Workstation (from 95-98 times), and XP 64 - a different desktop operating system, based on Windows 2003, and it rocked. And Windows 98 was absolute crap, 98 SE2 was somewhat tolerable, assuming you weren't using the network stack. By comparison, NT4 Workstation was rock-solid, but with smaller driver support and the need for huge amounts of ram.
While it is usual for cellphones to perform upscale of the photographed image, the big problem is sensor size. Given the same cells (MP), the bigger the sensor, the better the quality of the picture is. The smaller the cell size, the bigger the noise is in relation to the light captured. That's one of the reasons why the DSLR with 8MP will usually take a better picture than a 12MP compact camera.
It is also usual to put those "special" drivers on Linux upon install. Or to set some BIOS flags so Linux can actually boot. Server stuff uses a lot of custom hardware designed for a specific series, so it's not uncommon to have to provide extra drivers from the manufacturer upon install. Desktop hardware is a whole different game - the base schematic is usually the same, with some performance enhancements. I've yet to find a working desktop that has driver problems with windows.
I'm not saying I haven't had any problems with Windows drivers, just not with those bundled with Windows itself. I've had lots of issues (with several machines, different Windows versions and printer models) with HP - so much I've stopped buying any printer from HP, for example.
Are you shure your network controller is actually from Intel?
That's why drivers should be secondary to the OS code. In Vista and Windows 7, most drivers run in userspace, so if a driver crashes, it won't take down the whole operating system. The NT line of operating systems and its descendants use a hybrid kernel, while Linux is a traditional monolythic kernel. Linux is usually praised by its drivers "out of the box", but I've yet to see a windows machine crash with the supplied drivers, and I've had problems with some of the half-assed incomplete funcionality provided by linux kernel drivers.
While I agree that MS has treated C/C++ developers as second-class citizens, while trying to push the .NET dogfood (and aparently while rewriting all the Longhorn managed code back to c/c++), .NET isn't a failure in any way. Microsoft may be trying to swing it to the mobile market with little success, but on enterprise it's a whole different story.
AFAIK you can build a linux kernel without iso9660/joliet support and pack it on a distro. The fact that it is a "linux distro", it doesn't automatically mean than it can mount cd's out of the box.
PC-BSD does it, without breaking compatibility with the underlying FreeBSD. If you install a pbi package, it contains all the dependencies necessary to that given program and is installed on a separate dir. If you want to use the ports tree or install prebuilt packages, just use the default tools.
In fact, the problem you mention is probably one of the reasons I don't use linux on servers - on multi-purpose machines, I usually use FreeBSD with a bunch of jails, one for each kind of service (eg. database, mail filtering, mail server, www, etc), allowing me to upgrade each jail separalely without modifying other running services, at the cost of somewhat more expensive inter-jail comunication.
Except that you already have PCIe bus on a cable (external PCIe x8 adapters already exist, and more will appear until the end of the year).
2-3KW Gasoline generators are dirt cheap in construction equipment stores, and you can run them several hundred meters away from the shooting site. If you need more power, you can rent professional generators. Also, there are a ton of car inverters (used for everything from caravans to powering laptops) on the 100W-1000W range. Over that, you'd need to connect it directly to the battery because of the required current.
As for silent options, you have portable sine inverters such as Explorer XT (350W, good enough for led lighting), and a whole range of ruggerized battery lights from Peli.
Many outdoor filmmakers are now using led-based lighting, so the 2000W mark is a bit high.