Eric suggests it's time to move on from C, and there are indeed better languages today that can help eliminate many classes of error.
Crystal is a rising programming language with the slogan "Fast as C, Slick as Ruby". It has some compelling features that make it more attractive than other modern language attempts like Go. You really can program in a Ruby-like language and achieve software that performs with the speed of a compiled language. And you can do systems programming in Crystal, too, because while it doesn't encourage you to use them for anything but systems programming and inter-language interfaces, it has pointers, and it can format structs as required to work on hardware registers.
But the greatest advantage of Crystal, that I have experienced so far, is that it provides type-safety without excessive declarations as you would see in Java. It does this through program-wide type inference. So, if you write a function like this:
def add(a, b)
a + b
end
add(1, 2) # => 3, and the returned type is Int32
add(1.0, 2) # => 3.0, and the returned type is Float64
You get type-safe duck-typing at compile-time. If a method isn't available in a type, you'll find out at compile-time. Similarly, the type of a variable can be inferred from what you assign to it, and does not have to be declared.
Now, let's say you never want to see nil as a variable value. If you declare the type of a variable, the compiler will complain at compile-time if anything tries to assign another type to it. So, this catches all of those problems you might have in Ruby or Javascript with nil popping up unexpectedly as a value and your code breaking in production because nil doesn't have the methods you expect.
There are union types. So, if you want to see nil, you can declare your variable this way:
a : String | Nil
a : String? # Shorthand for the above.
Crystal handles metaprogramming in several ways. Type inference and duck typing gives functions and class methods parameterized types for free, without any declaration overhead. Then there are generics which allow you to declare a class with parameterized types. And there is an extremely powerful macro system. The macro system gives access to AST nodes in the compiler, type inference, and a very rich set of operators. You can call shell commands at compile-time and incorporate their output into macros. Most of the methods of String are duplicated for macros, so you can do arbitrary textual transformations.
There is an excellent interface to cross-language calls, so you can incorporate C code, etc. There are pointers and structs, so systems programming (like device drivers) is possible. Pointers and cross-language calls are "unsafe" (can cause segmentation faults, buffer overflows, etc.) but most programmers would never go there.
What have I missed so far? Run-time debugging is at a very primitive state. The developers complain that LLVM and LLDB have changed their debugging data format several times recently. There's no const and no frozen objects. The developers correctly point out that const is propagated through all of your code and doesn't often result in code optimization. I actually like it from an error-catching perspective, and to store some constant data in a way that's easily shareable across multiple threads. But Crystal already stores strings and some other data this way. And these are small issues compared to the benefits of the language.
Lucky
Paul Smith of Thoughtbot (a company well-known for their Ruby on Rails expertise) is creating the Lucky web framework, written in Crystal and inspired by Rails, which has pervasive type-safety - and without the declaration overhead as in Java.
The point of all of this is that you can create a web application as you might using Ruby on Rails, but you won't have to spend as much time writing tests, because some of the
I just use a PO box. It's not just your domain registration that makes an address public. It's a registration of businesses or charities, many things you do with the government. For a while Garmin GPS systems had business registrations programmed into the address database, and you could just type "Perens" in, and it would lead you to the address of my LLC, which was my home at the time. Now my business no longer has my name, and uses a PO box. Anyone who tried could find me anyway.
I'm sure there are some bad oncologists in the world, but: 1) everyone gets cancer if they live long enough and 2) the most common response to a condition like this coming up is to keep watching it. Not to treat it. If I had this, I'd want imaging once in a while just to make sure it wasn't becoming a problem.
Back in the desktop era, PC manufacturers didn't want Intel to have good graphics. Graphics card upgrades had much higher margins than the base PC. So, you can consider that Intel graphics have been deliberately handicapped.
I've been in this long enough to remember when the big graphics company was Silicon Graphics, and before that Evans and Sutherland. Intel just needs to hire good people.
Let's hope this try goes better than Intel's last attempt at making better graphics chips (which seemed to fizzle out), and better than things like Xscale which Intel discontinued before the market was really ready for it. Qualcomm would probably not be at the top of wireless handset chips now now, if Intel had kept Xscale going.
I think the Devuan developers also wanted to be in a community of people with different values. One that they felt would be more attuned to the Unix philosophy. One where something like SystemD would never have been considered as the default. You might have noticed that their announcements are signed "Vetran Unix Admins". Now, I know some people still with Debian have been around for a long time. But maybe they haven't held the same values.
And much as I love Debian, there is a lot wrong with it and has been for a long time. The inward-facing nature of it that holds it back: "we make Debian for ourselves". So much anal-retentive process that I wouldn't dream of attempting to re-qualify as a DD and going through all of it today. Way too much willingness to allow commercial distributions, often built on Debian, to run away with their user base.
So, I'm happy to see a non-profit fork with different goals, and maybe to help them a little.
Phil, I think the problem is that SystemD isn't just an init. And some of the things it took over were no longer maintained outside of SystemD until the Devuan people came along.
So, I think you should look at Devuan as not just Debian with a different init, but Debian with all of the problems of running without SystemD solved.
Hi Phil, Unfortunately a lot of packages are built with a dependency on libsystemd0. Satisfying this dependency, obviously, does not mean that your init system has to be SystemD. You may also stub out the library as necessary, or re-implement it to work with multiple init systems.
The breaking point for me was a filesystem problem on my root disk. Using another init, I would not have needed a rescue disk. Using SystemD, I could not boot without being able to write the journal. Devuan repairs that issue.
So, it's solving a problem vs. ritual purity. The purpose is not to eradicate every last work by Mr. Pottering, but to allow choice of init systems.
That would be very funny. Bruce and his select cohort of ninjas parachute into Debian Headquarters and hold a gun to the head of the DPL until he signs over project leadership. We hold him hostage to assure cooperation of the developers.
OK, before some noob calls the police, there is no Debian headquarters, it's a virtual organization.
question: what would happen if i did that? created an alternative which included systemd *in* devuan? would the devuan developers accept it? no they would not... because i have spoken to them and they are ABSOLUTELY adamant that systemd be excluded from devuan.
Well, logically you should give that piece to Debian. It would fulfill Debian's (ill-considered, IMO) decision to include SystemD, and would make life easier for Devuan, and it's nice for Debian to make life easier for its derivatives. Now, I guess Debian could be a stick-in-the-mud about that. Have you asked them?
I own four pieces of antique farm equipment that I no longer need to help pick cotton.
If no Devuan developer can use an old PC, some school can use it, and a volunteer who keeps it going. Since Microsoft is being much nicer to Open Source these days but once in a while still shows that they don't get it, I'd suggest you use Linux.
I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce.:-)
With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD. However, it is entirely possible for you to create what you believe is missing in Devuan, and provide it. You can ignore the fact that such a thing would be more for a ritual definition of universality than for anyone to practically use it - since you have stated your own belief that fulfilling that definition is important.
I was the second Debian project leader. These days, I prefer to run Devuan, a true Debian derivative engineered the way I would probably have decided to make it. It's efficient and trouble-free. Thanks to the Devuan developers for all of the work!
The cells have been produced in the "Gigafactory" for a year and a half now. Certainly Panasonic participates, but I'd say the cells are made by a partnership of Tesla and Panasonic now, and the packs are made by Tesla. Also note that Tesla is the only auto manufacturer to own a cell plant at all, all of the other manufacturers purchase cells.
If you look at SpaceX, they do a lot more in-house than any other rocket maker. So no surprise that Tesla would attempt to take into house the biggest blocker for electric cars - the batteries.
The batteries alone seem to be a successful product, generating $410M in revenue just in Q1, and with about half a giga-watt-hour installed. Solar installations are down significantly, but this may because they Osborned themselves and their customers are waiting until they can install private energy storage.
But
IMO this is all small next to the fact that they have the first practical electric car, meaning a car that competes successfully with gasoline automobiles on their own turf rather than being desirable simply because they are electric.
TI and Kirby actually could not sell their ICs. Besides, the IC that Kirby patented wasn't monolithic, so it's not a real IC. That was invented by Intel. The Apollo guidance computer was the first practical application of integrated circuits and drove their development.
I'm pretty sure that staying on one planet is suicide. Even if we figure out how to run a government to take care of it, there are natural disasters that aren't survivable bu any means but "leave".
Slashdot Mirror
Eric suggests it's time to move on from C, and there are indeed better languages today that can help eliminate many classes of error.
Crystal is a rising programming language with the slogan "Fast as C, Slick as Ruby". It has some compelling features that make it more attractive than other modern language attempts like Go. You really can program in a Ruby-like language and achieve software that performs with the speed of a compiled language. And you can do systems programming in Crystal, too, because while it doesn't encourage you to use them for anything but systems programming and inter-language interfaces, it has pointers, and it can format structs as required to work on hardware registers.
But the greatest advantage of Crystal, that I have experienced so far, is that it provides type-safety without excessive declarations as you would see in Java. It does this through program-wide type inference. So, if you write a function like this:
def add(a, b)
a + b end
add(1, 2) # => 3, and the returned type is Int32
add(1.0, 2) # => 3.0, and the returned type is Float64
You get type-safe duck-typing at compile-time. If a method isn't available in a type, you'll find out at compile-time. Similarly, the type of a variable can be inferred from what you assign to it, and does not have to be declared.
Now, let's say you never want to see nil as a variable value. If you declare the type of a variable, the compiler will complain at compile-time if anything tries to assign another type to it. So, this catches all of those problems you might have in Ruby or Javascript with nil popping up unexpectedly as a value and your code breaking in production because nil doesn't have the methods you expect.
There are union types. So, if you want to see nil, you can declare your variable this way:
a : String | Nil
a : String? # Shorthand for the above.
Crystal handles metaprogramming in several ways. Type inference and duck typing gives functions and class methods parameterized types for free, without any declaration overhead. Then there are generics which allow you to declare a class with parameterized types. And there is an extremely powerful macro system. The macro system gives access to AST nodes in the compiler, type inference, and a very rich set of operators. You can call shell commands at compile-time and incorporate their output into macros. Most of the methods of String are duplicated for macros, so you can do arbitrary textual transformations.
There is an excellent interface to cross-language calls, so you can incorporate C code, etc. There are pointers and structs, so systems programming (like device drivers) is possible. Pointers and cross-language calls are "unsafe" (can cause segmentation faults, buffer overflows, etc.) but most programmers would never go there.
What have I missed so far? Run-time debugging is at a very primitive state. The developers complain that LLVM and LLDB have changed their debugging data format several times recently. There's no const and no frozen objects. The developers correctly point out that const is propagated through all of your code and doesn't often result in code optimization. I actually like it from an error-catching perspective, and to store some constant data in a way that's easily shareable across multiple threads. But Crystal already stores strings and some other data this way. And these are small issues compared to the benefits of the language.
Lucky
Paul Smith of Thoughtbot (a company well-known for their Ruby on Rails expertise) is creating the Lucky web framework, written in Crystal and inspired by Rails, which has pervasive type-safety - and without the declaration overhead as in Java.
The point of all of this is that you can create a web application as you might using Ruby on Rails, but you won't have to spend as much time writing tests, because some of the
I just use a PO box. It's not just your domain registration that makes an address public. It's a registration of businesses or charities, many things you do with the government. For a while Garmin GPS systems had business registrations programmed into the address database, and you could just type "Perens" in, and it would lead you to the address of my LLC, which was my home at the time. Now my business no longer has my name, and uses a PO box. Anyone who tried could find me anyway.
I'm sure there are some bad oncologists in the world, but: 1) everyone gets cancer if they live long enough and 2) the most common response to a condition like this coming up is to keep watching it. Not to treat it. If I had this, I'd want imaging once in a while just to make sure it wasn't becoming a problem.
You've never heard of Skene's gland.
Back in the desktop era, PC manufacturers didn't want Intel to have good graphics. Graphics card upgrades had much higher margins than the base PC. So, you can consider that Intel graphics have been deliberately handicapped.
I've been in this long enough to remember when the big graphics company was Silicon Graphics, and before that Evans and Sutherland. Intel just needs to hire good people.
Let's hope this try goes better than Intel's last attempt at making better graphics chips (which seemed to fizzle out), and better than things like Xscale which Intel discontinued before the market was really ready for it. Qualcomm would probably not be at the top of wireless handset chips now now, if Intel had kept Xscale going.
Intel is making graphics chips, and IHOP is making hamburgers.
I think the Devuan developers also wanted to be in a community of people with different values. One that they felt would be more attuned to the Unix philosophy. One where something like SystemD would never have been considered as the default. You might have noticed that their announcements are signed "Vetran Unix Admins". Now, I know some people still with Debian have been around for a long time. But maybe they haven't held the same values.
And much as I love Debian, there is a lot wrong with it and has been for a long time. The inward-facing nature of it that holds it back: "we make Debian for ourselves". So much anal-retentive process that I wouldn't dream of attempting to re-qualify as a DD and going through all of it today. Way too much willingness to allow commercial distributions, often built on Debian, to run away with their user base.
So, I'm happy to see a non-profit fork with different goals, and maybe to help them a little.
Phil, I think the problem is that SystemD isn't just an init. And some of the things it took over were no longer maintained outside of SystemD until the Devuan people came along. So, I think you should look at Devuan as not just Debian with a different init, but Debian with all of the problems of running without SystemD solved.
Hi Phil, Unfortunately a lot of packages are built with a dependency on libsystemd0. Satisfying this dependency, obviously, does not mean that your init system has to be SystemD. You may also stub out the library as necessary, or re-implement it to work with multiple init systems.
The breaking point for me was a filesystem problem on my root disk. Using another init, I would not have needed a rescue disk. Using SystemD, I could not boot without being able to write the journal. Devuan repairs that issue.
So, it's solving a problem vs. ritual purity. The purpose is not to eradicate every last work by Mr. Pottering, but to allow choice of init systems.
That would be very funny. Bruce and his select cohort of ninjas parachute into Debian Headquarters and hold a gun to the head of the DPL until he signs over project leadership. We hold him hostage to assure cooperation of the developers.
OK, before some noob calls the police, there is no Debian headquarters, it's a virtual organization.
Ego? Nah. If I really had that kind of ego, I'd be telling you about my huge... oh, never mind.
Well, logically you should give that piece to Debian. It would fulfill Debian's (ill-considered, IMO) decision to include SystemD, and would make life easier for Devuan, and it's nice for Debian to make life easier for its derivatives. Now, I guess Debian could be a stick-in-the-mud about that. Have you asked them?
If no Devuan developer can use an old PC, some school can use it, and a volunteer who keeps it going. Since Microsoft is being much nicer to Open Source these days but once in a while still shows that they don't get it, I'd suggest you use Linux.
I've had my own ideas about how to "better" engineer Devuan, but there are so many things to do and so little Bruce. :-)
With respect, I think your argument is mooted by the fact that Debian itself exists and is a viable alternative if you want to load SystemD. However, it is entirely possible for you to create what you believe is missing in Devuan, and provide it. You can ignore the fact that such a thing would be more for a ritual definition of universality than for anyone to practically use it - since you have stated your own belief that fulfilling that definition is important.
Thanks
Bruce
I don't represent the Devuan developers. They have a web site :-) Please communicate with them directly. Thanks!
I was the second Debian project leader. These days, I prefer to run Devuan, a true Debian derivative engineered the way I would probably have decided to make it. It's efficient and trouble-free. Thanks to the Devuan developers for all of the work!
The cells have been produced in the "Gigafactory" for a year and a half now. Certainly Panasonic participates, but I'd say the cells are made by a partnership of Tesla and Panasonic now, and the packs are made by Tesla. Also note that Tesla is the only auto manufacturer to own a cell plant at all, all of the other manufacturers purchase cells.
If you look at SpaceX, they do a lot more in-house than any other rocket maker. So no surprise that Tesla would attempt to take into house the biggest blocker for electric cars - the batteries.
The batteries alone seem to be a successful product, generating $410M in revenue just in Q1, and with about half a giga-watt-hour installed. Solar installations are down significantly, but this may because they Osborned themselves and their customers are waiting until they can install private energy storage.
But IMO this is all small next to the fact that they have the first practical electric car, meaning a car that competes successfully with gasoline automobiles on their own turf rather than being desirable simply because they are electric.
You mean like the cretaceous bottleneck?
You don't have to understand them. Just be absolutely sure never to use glyphs containing aubergines or peaches, or especially both together.
Obviously not you :-)
Fairchild, not Intel. Sold and spun off again three times, so although the name belongs to On Semiconductor, it doesn't really exist any longer.
TI and Kirby actually could not sell their ICs. Besides, the IC that Kirby patented wasn't monolithic, so it's not a real IC. That was invented by Intel. The Apollo guidance computer was the first practical application of integrated circuits and drove their development.
Kirby and Texas Instruments couldn't sell their integrated circuits, so they don't count. ICs were developed for the Apollo guidannce computer.
I'm pretty sure that staying on one planet is suicide. Even if we figure out how to run a government to take care of it, there are natural disasters that aren't survivable bu any means but "leave".