Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I wanted to ask how an application update works. I don't get it! I give you an example of GTA V.
When Rockstar releases a patch or update, how do they update the code without downloading the whole GBs/MBs again or recompiling it? After the update you can easily start the game.
I saw similar methods on other games. They modified e.g 2MB of code and the updater downloads only the 2MB. The modified code goes into the game without recompiling... Am I stupid or why don't I get how that works? ... I mean, if there is a 50MB big .DLL file and the devoloper edited only 1 line, the updater doesn't download the 50MB again, to the contrary it just gets the 1 edited line and yeah... It's in ._.*...
I think you are not aware of the possibility to apply binary patches.
Basically the idea is that if the change in the source code is small and the binary files are recompiled, a very large part will be identical. This can be exploited to release a patch that is also small in size.
For example, suppose that of your 50 MB binary only 10 bytes are changed. A smart tool could do this: take the old file, ignore the first 23,678,789 bytes, then replace the next 10 bytes with the content of the patch, delete 2 more bytes, ignore the next 4332 bytes, add one, and leave everything else untouched. In an appropriate format, this patch would only require a few bytes.
Of course it is reasonable that the full patch contains a hash of the original file and of the modified one, to make sure that everything goes smooth, and in case of disasters you could fall back to downloading the entire file anew. And you could add signatures to ensure that only authorized patches are installed. But the basic idea is that you can do binary diffs and patches, and this is absolutely common.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I am thinking of using base64 encoded images for a site I am working on to optimize the load time.
Anyways, before I start, I was wondering: what are the advantages and disadvantages of doing this?
At the moment, I don't see any disadvantage but also I noticed that it is not a technique used very often and that makes me wonder if I didn't miss something.
After googleing the subject I didn't find anything clear so I decided to ask here.
It's only useful for very tiny images. Base64 encoded files are larger than the original. The advantage lies in not having to open another connection and make a HTTP request to the server for the image. This benefit is lost very quickly so there's only an advantage for large numbers of very tiny individual images.
the actual length of MIME-compliant Base64-encoded binary data is
usually about 137% of the original data length, though for very short
messages the overhead can be much higher due to the overhead of the
headers. Very roughly, the final size of Base64-encoded binary data is
equal to 1.37 times the original data size + 814 bytes (for headers).
In other words, the size of the decoded data can be approximated with this formula:
bytes = (string_length(encoded_string) - 814) / 1.37
Source: http://en.wikipedia.org/wiki/Base64#MIME
Some of downsides as below are already mentioned in this post at How much faster is it to use inline/base64 images for a web site than just linking to the hard file?
Most forms of caching are beaten which could hurt a lot if the image is viewed often - say, a logo that is displayed on every page, which could normally be cached by the browser.
More CPU usage.
also the response time of the HTML page will increase, because images loads asyn in normal scenario. even if images loads late you can start seeing text.
Another advantage of CDN would lost if only media is being cached in CDN
that advantage will be lost.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am planning to use an HID barcode reader to spool data then it will be read as a data source for Microsoft Access? Is this possible? Can I do it in the background? Thanks.
To answer your question, if you have a barcode reader that creates a .CSV or .TXT file with a list of barcodes, yes, you should be able to import the list into Access. (Any valid .CSV file, and most well-structured .TXT files.)
This Stack Overflow post shows how to load a CSV file using VBA.
And here's how to do it manually.
Questions about the specific model are off-topic for this site but since I was the one that asked for that information, I did look into it quickly...
Symcode MJ2090
It looks like this product is made specifically for sale on Amazon/eBay, and every page I clicked has the identical copy/pasted description.
It raises an alarm for me that the "standard description" doesn't specify how the data is output to the computer other than "USB, No Driver Required".
Also, the Chinese manufacturer's sketchy site gave me browser security warning, and then doesn't even list this product in their list of BCR's. Perhaps it was a failed product that they unloaded cheap to resellers.
I've bought cheap USB electronics in the past (recent example: SIM Card reader/writer) which, while one would assume include the software necessary to use the product, that's not always the case, and since the description didn't actually say it includes software, they didn't break any rules and the item is now nonreturnable due to delay, etc.
Technically, if I was so inclined (and skilled in the correct areas) I could write software to communicate with my device, but that would be the equivalent of writing a printer driver from scratch.
My point is, be 100% sure how the device send the data to the computer before purchasing, or else shell out a few extra bucks for a known brand name instead of a no-name product.
I didn't look very closely but when searched eBay for USB barcode reader, sorted by "lowest price + shipping", the first result was this one is $18 USD (free shipping) and specifically says:
Supported Interfaces: RS232 / PS2 keyboard / USB
...although it's wired.
Or this one is $25 USD (free shipping) is wireless and says it:
Supports instant upload mode and storage mode(store 200 barcodes).
..which sounds promising, but "supports" doesn't mean it "does it"... however it's easy to contact the seller and find out.
Price aside, looking at a reputable store, I think this $80 USD model would work for you, but you'll need to check the documentation from the [reputable] manufacturer (Motorola) into it further to confirm. (I've never bought one.)
Or, I betcha this $10000 model will work too. :-)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have read all the existing discussions on piracy and hardware support, so this is not the same old question. I have a new twist on this old discussion. You can now purchase dongles for USB that allow you to put some of your important code into the dongle. If you have a complex algorithm and you put it into the dongle, someone would have to reverse engineer the contents of the dongle. If they tried to spoof the dongle, as was possible in the past, this would not work. All they can see is that data goes into a "black box" and result data comes out. It is no longer a matter of finding a jump true/false to bypass a license check in the source code.
Perhaps a mathematician with a lot of idle time on his hands could eventually reverse it, but that is an extreme level of interest! The other option is that the hardware dongle itself would need to be hacked. There are many protections against this built in, but this is probably the most effective approach.
So I want to take a scenario and see if I've missed something. I put the important part of my algorithm into the dongle to protect it. 6 doubles and 1 int go into the dongle, 1 double and 1 int are returned. This happens for thousands of data points. This is one of several functions of similar complexity. A hacker can see the rest of my assembly code (which I do as much as possible to obfuscate), but lets assume it is easily hacked. My question is, how hard is it to break into the dongle to access my assembly code in this proprietary hardware? Let's take as an example this companies product: http://www.senselock.com
I am not interested in lectures on how I'm inconveniencing customers and should open source my product, please. I am looking for a technical discussion on how a software/hardware engineer might approach extracting my assembly object from such a device. And I am not asking in order to hack one, but to know how much hassle I have as my discouragement against tampering. I know if there is a will, there is always a way. But at first glance it looks like it would take several thousand dollars worth of effort to bypass this scheme?
Given the response so far, I am adding some more specifics. The dongle has the following property, "Access to the chip is protected by PIN, and the maximum re-tries is pre-set by software developers. For instance, under a dictionary attack, once the number of re-tries exceed the pre-set value, the chip will trigger a self-locking mechanism". So to access the chip and thus the code inside it, you have to know the PIN, otherwise after let's say 10 tries you will be locked out. I personally can't see any way anyone could compromise this system. It doesn't matter what goes in or out, what matters is what runs inside the dongle ARM processor. Physical forced access would destroy the chip. Electrical access would require the PIN, or the chip locks up. How else could it be compromised?
I pretty much agree with your point of view that all dongles could be hacked, it just the matter of time and cost. If your encryption scheme is well-designed the EAL 5+ chip should be secure enough to prevent your software form malicious attacks.
And I think if you can READ the dongle it's probably means you already hacked the dongle, or it proofs there is a fatal vulnerability in the encryption scheme.
BTW, the link you give above is not work. Are you referring to this dongle? http://www.senselock.com/en/productinfor.php?nid=180&id=142&pid=
there are companies(such as break-ic.com) which have the list of mcu which they can break.
after breaking they give you only hex files.
in this case(mcu)every manufacturer has its own disassembler because of hardware architecture of every mcu core and there is no guarantee that your desire disassembler is exist!!!
so you must search for dongles which they have unbreakable mcu or their mcu has no disassembler.
or you can build you own dongle!!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
What do you do with GitHub repositories you no longer maintain?
For whatever reason a project is started with a GitHub repository and then sometime later it's abandoned Perhaps it was an experiment that didn't work out. Perhaps you replaced it with a commercial product. Or perhaps you found a similar project to what you were doing and joined their efforts instead.
In the time your repository was alive, it attracted watchers and a few forks.
What do you do with it at that point? Is there a way to nicely indicate that repository is no longer maintained and to either check out the forks or a different project?
I'd do a single commit that removes all the source except for a README file that clearly states that you no longer have interst in the project (also copy the important parts of the README to the last commit log message, use git commit --amend if needed).
The README should explain that all the source code is still available as history. In addition the state of latest code should be described for maturity level: if it was used in production somewhere, it should be said here. If it was only an experiment and you never got it to compile correctly, then that should be said in capital letters. In the latter case, it might make some sense to just remove the code repository, though.
Obviously, the README should also contain the generic description of what your code does, but that should be already in the README.
Also try to put some words in the README that you expect potential users of that code to look for. Try to put those words close to the part that says that you're no longer maintaining the code.
The reasoning for this:
anybody interested in your source will still be able to get it (through history)
anybody trying to blindly merge your HEAD with his will immediately see that it's a bad idea (all source code will be removed and replaced with a README that explains why this happened)
I don't agree with the suggestion that if nobody has forked (and preserved the code), it's worth nothing. Perhaps the only reason somebody else has not taken over is that your project haven't been seen by enough many eyeballs.
If you believe that your code has any value (and I do mean anything above zero), then do not delete it. Just make it clear that the code has been abandoned.
Actually, I think pretty much the nicest thing you can do is to simply delete the repository. That way, the obsolete code doesn't show up in searches, for example.
The whole point of distributed version control is that no single repository is more important than another. If there is enough interest in the project, then one of the people who forked the repository will emerge as the new community leader. And if nobody forked it, then it probably wasn't worth preserving anyway.
I'd make a nice commit in the README file which basically states that this is here for historical reference, look at X Y and Z in order to see where this code went.
I prefix my projects with "deprecated." There are some posts on github's site regarding this, but it seems they won't budge. They want you to put a note in the readme. I'd prefer to put information in a relational database so you can sort on different fields, one of those being if the project is active or not.
I put my deprecated projects up there because there are concepts you can re-use. It is similar to your school work. Hopefully you can learn a lesson or 2 from it.
Walter
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This question is about etiquette and open source projects.
I have forked an application from github and added two new features.
The first feature has been request frequently elsewhere. I have added it. Code & implementation are clean (I think).
The second feature is more of a hack. It will be of use to others, but the implementation is a little dirty in useage and more so in code. I need the feature but I don't have the skills to fully implement it properly or to a level that could be considered a worth while contrabution to the main project.
How should the versioning work? Do I just bump up my version numbers care-free and push to my master branch?
It is annoying to know which version is running, modifed or original, as both have the same version number. But will it be confusing when, months later, my github page has a version number the same as the original but both are actually completely different. (I have made pull requests etc. but that is not the context of my question.)
The project I have forked uses ruby jeweler so has a versioning format of:
Jeweler tracks the version of your project. It assumes you will be using a version in the format x.y.z.
x is the 'major' version, y is the 'minor' version, and z is the patch version.
Is this standard for other projects/langauges too? Are my changes patches?
Thanks
This can't be answered easily. Version number handling varies between projects and your goals. Do you see your fork as a temporary issue? - Then, in many cases (might be different with larger rewrites for example), I won't increase the version number as it is up to the project leader to do.
Many versioning schemes allow to extend the version number to something like 1.2.3-ross, which helps users filing proper bug reports.
If you plan a longer running fork you should find a versioning scheme which works for you.
Different pieces of software from the same code base but with different feature content should have different version numbers in some way - so you need to change something in the version number (or product name).
Do you plan to submit the first change back to the project? (You probably should.)
Is the second feature, the hack, one that you will improve over time? You might keep it on your own development branch so it is easier to maintain separately while still importing updates from the main project.
Or are you planning to stay separate from the main project in perpetuity? In that case, you should consider renaming the software as well as changing the version - or somehow making it clear that the version is yours and not theirs.
If you intend to fork, which is to say never merge back with upstream, then consider renaming your project.
Otherwise, it's common to use a version number that indicates the branch and changeset being ran ala -git-ross-12345