Eh, not really, it's just going to require an exponential increase in computing power. They already have the platform, in theory it would just be about scaling.
That said, it's kind of a huge scaling problem. If it really is a matter of throwing more hardware on it, and they currently use, say, 100 servers, they're going to need 429496729600 servers to get the same times they are getting now.
Maybe not that many, but still a lot more, if you first looked at BGP, and only brute-forced networks that were routable, rather than the entire search space.
Basically, before scanning, query and iterate all ASes advertisments and union present ranges, then feed that to zmap or something that can scan IPv4 and/or IPv6.
Not who you replied to, but I, personally, think it boils down to trust. Using someone else's code, _especially_ if it's functional, should be the same as using the proverbial black box. You shouldn't need to understand their code in order to use it with your own. The same should be true of your own code, really. You shouldn't need to remember implementation details of a function you wrote in order to use it in elsewhere in your code.
I know there's then the issue of security, freedom, openness. . .whatever. But if you're working on a project with someone else, and you don't trust them, the project's probably doomed to fail to begin with.
I liked this article, but I feel like it's just a bit too. . .matter of fact. "FP _will_ make your linter do your work for you", things like that.
("Even if you haven't already-made a mistake, and are just thinking of making a change to a codebase, the # FP version of the code is a lot easier to think about than the # Imperative version" was particularly bad about this. I have never had a problem paralellizing a procedural program that would have been solved using FP)
It is _much_ better at being inclusive and not preachy than other articles of similar scope. But I would prefer if posts like this tried to explain functional programming without feeling the need to put down other paradigms. And, to be clear, I'm a big fan of FP, and have been using many of its tenants for a long time now.
Functional programming is just a different way to structure a code base. Some people are better able to grasp how data flows through a maze of functions. Some people are better able to grasp how an object interacts with other objects.
In the end, it's all just a sequence of instructions executed, in order, by a machine. The true correct way of writing code is: However you can get that machine to do what you want it to do, while still being able to make changes to its behavior.
Frankly, it's just a different way to think about structuring a code base.
Some people think better functionally, some people think better procedurally, but, in the end, it's all just a list of instructions, executed in order by a machine.
I'll never understand the need to poopoo all over someone else's way of thinking (not you, the guy you're replying to).
That's like saying monarchy and democracy are just different ways of structuring a society. Some people think better monarchically, some people think better democratically. Why poopoo all over someone else's way of thinking?
Honestly, I wouldn't respond to anyone who compares political systems with software development paradigms. Realistically, it's just really hard to compare the two directly, and anyone who says otherwise is trying to sell you something.
No, it really doesn't. Windows has had backwards compatibility as a huge priority for a long time, often to their detriment. You can literally update a machine from Windows 3.1 to windows 10, and programs written for Windows 3.1 will still work.[1]
EDIT: TO be clear, this is a video of upgrading to Windows 7, and there is a direct upgrade path to 10 from 7. Also, as per another user's reply, this doesn't hold true for 64-bit. However, that doesn't change the fact that Wine doesn't and really can't run win32 better than win32 does.
They made a decision to cut the compatibility but also made the 32bit XP mode VM ship with windows for a transition period (unsure if it's still available). I think it feels like a fair compromise (assuming the VM only causes an overhead for those who need it, but having a whole kernel subsystem for legacy apps might mean security or performance issues for all users)
That's interesting. I didn't actually know that, I figured there'd be some kind of shim in place to make it work. Incidentally, this doesn't mean that Wine runs 16-bit Windows programs particularly well. I did a bit of quick research, and it turns out you need to jump through some hoops to run 16-bit on Wine.[1]
I maintain that Windows is always a better choice for running win32 applications, unless you don't have that option. I'll also note that I'm not saying Wine is useless, or anything along those lines. I merely take issue with the idea that it runs win32 applications "better" than a system that's designed to be backwards compatible with win32 applications by the same entity that made win32.
Both WoW64 and Wine provide an environment that pretends to be 32-bit Windows and presents the Win32 API, but neither one is actually Windows XP. I've had pretty similar experiences trying to run old win32 games on both systems (i.e. it's hit or miss) but Wine has the significant advantage that it will allow a program to think it has admin privileges when it doesn't. Also under Wine, I've had better luck running games from ISOs I've ripped, where I have to insert an actual CD in a physical drive for the program to run under Windows.
Open source does not mean you are free to distribute the code, necessarily. It literally just means that the code is available for inspection. Paid-for open source software isn't a new thing.
You're thinking of _free_ open source software. While I'm not a huge FOSS-head, there is a distinct difference between "_free_ and open source" and just "open source". It's all in the licensing.
I could, in theory, write a license that says, basically, you can't distribute my source code, but you can look at it, compile it, and even alter it to fit your needs. In fact, a lot of licenses on older software projects allowed for exactly that.
I could also release a license that says that you can only redistribute my code if you haven't purchased it, but if you have purchased it, you're not allowed to redistribute it. Pointless? Yeah, probably. But that's still a valid license.
Anything goes, as long as you can come up with the proper legalese to put in the license.
EDIT: I get it, some people support OSI's definitions, some FSF's, and apparently sharing the opinion of one has angered the supporters of the other. A lot of this is subjective, and I know that. I'd appreciate it if you discussed and voted accordingly.
> I could, in theory, write a license that says, basically, you can't distribute my source code, but you can look at it, compile it, and even alter it to fit your needs.
You can, but this doesn't meet the Open Source Definition, so you might be infringing on their trademark if you were to call that an Open Source License.
> While I'm not a huge FOSS-head, there is a distinct difference between "_free_ and open source" and just "open source". It's all in the licensing
"Free Software" and "Open Source" mean pretty much the same as far as the practices, motions and licenses are concerned (but people insist there are huge differences in terms of philosophy). "Free and Open Source Software" is just a new-ish term that includes either team to stop the whining.
"Open Source" was a mostly unused term in the software licensing field before 1998 or the people at OSI who drafted the Open Source Definition likely would have gone for something else.
"Shared source" was introduced by Microsoft a couple years later and is a pretty descriptive term for those less liberal licenses (where sharing code happens outside the criteria of the OSD).
Why not just go with that instead of arguing why people should use a term to mean something different?
There was an effort to do just that, by Microsoft, to muddy the waters, before they settled on "shared source", which might be why you get those harsh responses.
No, when hear the term open source the first thing that come in mind is that the source is readable, thats it nothing else is implied. That being said, oher entities/organization might have their own definition. I'm sure there are many people who use the term open source like mine.
Lots of people get technical language wrong much the time. This is fine. Normally one does not correct heavily because one is polite. When one hears someone starting to spread the mistake one feels a duty to correct to prevent further misinformation. This is tedious but still fine.
What is not fine is when the person using the technical language wrong starts explaining that their ignorance is better than other peoples' knowledge.
No it's not ignorance its willful ignorance. There is the actual definition. And then there is your personal definition.
This is like saying that personally you use the definition of kilogram to be 3.5 measures of flour using one of your cups. You would struggle when using other people's recipes and other people would struggle when using yours....
Software licensing is complex enough already. Why not keep it all simpler and use words as they are defined and understood by the lawyers who are the ones who actually have to deal with this side of things? Then us programmers can just write the software.
Who decide that the OSI definition is the actual definition ?
Unlike your kilogram example, there are actually plenty of people that use/prefer the simpler definition, sure there will some struggle but that is expected.
That's why they should not use such simple and common words to define complex software licensing.
You're not alone. I'm of the mind that it doesn't matter what the license, state of the source, or whatever, I'm here to get things done, not quibble over trivialities and semantics. When I can see the source for something, I call it open source. If the OSI has a problem with that, I invite them to explain to me how my definition affects their goals in any way, shape, or form.
I like the OSI. I use a lot of stuff that they endorse. My 3D printer is OSI certified (or whatever the proper terminology is). But I use my printer to solve problems, and it being open or closed source doesn't really matter, so long as it helps me solve problems.
I like the FSF. I use a lot of stuff that they endorse. One of the operating systems I use is FSF certified (or whatever the proper terminology is). But I use this operating system to solve problems, and it being open or closed source doesn't really matter, as long as it helps me solve problems.
I like Microsoft. I use a lot of stuff that they make. One of the operating systems I use. . .you get the idea.
I recommend just using the definitions of things correctly then :) much easier that trying to persuade other people that the definition does not exist.
When cooking I use the kilogram as defined by the SI system - I don't use some other random mass that I call a kilogram.
Similarly with software legalities. I also just use the standard terminology so other people e.g. my company's legal department gets the correct inference of what I am talking about. If you use it to mean something else you will confuse them.
Correct or not is relative, its a matter of which definition you subscribe to.
Using the term Open source as source is available is not just random. Apparently many people including developer use it that way. I think its fault of OSI to use such common words to define something so specific.
I don't understand. Once someone knows that they are using these words wrong. Why would they not only persist but insist that everyone else is wrong? Is this just due to embarrassment or something else?
If you can look at, but not redistribute, freely, it is called 'shared source'.
Open Source really is about free redistribution. And the difference to Free Software is mostly about the stance on community and lock-in.
"Open source" is very generic, it literally just means "Not closed/private source." Nothing else about redistribution and restrictions is implied. For that there are specific licenses, which the article didn't mention.
It's not open source unless it's an open source license, and it's not an open source license unless it meets https://opensource.org/osd-annotated. You are referring to "source available". Please stop conflating the two.
Can you blame us? This is largely a subjective matter, and the different organizations who talk about this kind of thing have often-conflicting ideologies about how all this works.
When I hear "open source", I don't know which camp the speaker is sitting in. It's perfectly reasonable to get mixed up sometimes.
While it is a subjective matter when looking from the outside, the OSI consortium did a pretty good job of bringing in all of the various groups conventionally referred to as 'open source' and getting the various definitions pinned down in a way that seems to accurately reflect the broad spectrum of possibilities, even to the point that non-open-source companies use their definitions.
While I agree one can still certainly debate the legitimacy of this situation if one so desires, it's pretty much consensus 'within the literature' that the OSI definitions 'are correct' at this pont..
It is a technical term defined by a bunch of people who got together and agreed that their opinions (however educated they may be) are more correct than other people's. That's extremely subjective, and not universally accepted.
Technical terms have definitions that transcend the opinions of people who use them. When I say "byte", everyone knows exactly what I mean, as it's a unit of measurement. When I say "agile", it could mean any number of different things, depending on context. When people say "open source", the thought that comes to a lot of people's minds is simply "I can see the _source_ code, because it's out in the _open_."
It's subjective, and, frankly, annoying. It shouldn't matter how something is licensed, because the most important aspect of software is whether or not it provides value and helps me do my job. Bickering about semantics doesn't get work done.
That's how definitions work.
The fact that you ignore one doesn't make you more thoughtful or insightful it just makes you look like a special snowflake.
Your example is also incorrect because I'll assume you think that a Byte is 8 bits but technically it's not, it's an arrangement of bits a byte can be 0-255bits, it was common to have non 8bit bytes in the past.
The 8 bit byte was set by a specific ISO standard and later by IEEE but it's defined as 8 bits only within those standards.
Agile also has a definition if nothing else because you have bodies and various foundations promoting a specific implementation of it.
Any conflicts that exist are not conflicts in the definition of Open Source, but are different definitions for different terms which is why the terms open-source software and free and open-source software exist.
This isn't a subjective matter, this is a very well defined term, if nothing else because OSS and FOSS software is used in the industry including in commercial products this requires the definitions and the licenses to be very very specific to meet legal and regulatory requirements.
So while you can say there are different software licenses to meet the requirements of being Open Source it needs to meet the definitions set by the OSI which are in general mean that the source code must be available, that the distribution is not restricted in any way which usually means that it's distributed under a free and non-discriminatory license agreement.
You may chose not the follow this definition but this doesn't mean that this is a correct action, this is no more subjective than the definition of a kilogram.
Definitions exist for a reason and that is to remove ambiguity, if ambiguity exists its either because there is no definition or consensus which is clearly not the case with Open Source Software.
I'm just going off of what I hear vocal "FOSS" advocates screaming at me on online forums. They tell anyone and everyone, loudly, that licenses are terrible, but at least some are decent, and that if I can't do what I want, it's not free software, even if it's open source.
Turns out opensource.org disagrees with them. But it doesn't seem like FSF (or rather, RMS, and the FSF by proxy) agrees[1].
In the end, I don't really have a horse in this race. I just write code. I don't care how my company's legal department chooses to protect it.
Frankly, I find it kind of tiresome that there's such a big argument over this stuff.
I manually went through each of the OSI licenses and compared them to the FSF's list a while back, and there were only a couple differences. I don't have time to dig them up right now, but they're largely the same.
We reject the term "open source" not because of the licensing, but because of the philosophy: it was created to explicitly ignore the ethical concerns (users' freedoms) and focus instead on a development methodology.
Zachtronics is awesome. Not only do they make some of the best puzzle games in the world, their write-ups are always full of juicy details.
I really liked their modern take on "retro" programming. I am not of the mind that we need to start teaching every developer how to hack away at assembly, but there's no denying that working on limited hardware (like what is still found in embedded devices) benefits greatly from at least a passing familiarity of it. I think that's kind of what their goal was and is with games like TIS-100 and SHENZHEN I/O. Not necessarily to give seasoned assembly hackers fun games to play, though it certainly does, but to give younger programmers an idea of what working with low-level code can look like.
This article has made me want to re-install TIS-100 and see if I can;t finish some of the levels I struggled with. . .
I would love to see more posts like this. Seeing your thought process when approaching a problem, even if you don't end up solving the problem, or don't do it well, is valuable insight into how other people work, and how I can possibly integrate some of your methods to my own workflow.
That said, it's kind of a huge scaling problem. If it really is a matter of throwing more hardware on it, and they currently use, say, 100 servers, they're going to need 429496729600 servers to get the same times they are getting now.