I'm running Alloy 6 (6.1.0) for the first time. I've updated my syntax and am getting no error messages. But checking assertions (that were valid in Alloy 5) I am fairly often getting:
0 vars. 0 primary vars. 507 ms.
No counterexample found. Assertion may be valid. 0 ms.
This can't be right. What should I do?
The answer was given by private mail. The issue is not specific to Alloy 6 as this behavior is already present in Alloy 5: Alloy is in fact able to solve some assertions even without calling a SAT solver, hence the 0 in 0 vars. 0 primary vars. 507 ms. No counterexample found. Assertion may be valid. 0 ms..
Related
I've been referring to RFC 4034 (https://www.rfc-editor.org/rfc/rfc4034#page-4), but there is something I quite don't understand about the flags field of a RDATA for a DNSKEY RR.
As stated in the RFC 2.1.1. The Flags Field, "Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR and MUST be ignored upon receipt.".
But few lines under in 2.2. The DNSKEY RR Presentation Format, it states "The Flag field MUST be represented as an unsigned decimal integer. Given the currently defined flags, the possible values are: 0, 256, and 257."
How can bits 8-14 be required to have value of 0 if using 256 and 257 as the section value ?
Could someone explain to me if there is something I don't get please ?
I am currently building my own DNS server and I need to validate the format of a DNSKEY RR as well as craft packets on demand for them.
Thanks !
I am currently building my own DNS server
I hope it is mostly for learning, because otherwise this is a tricky matter!
You can (should) also study existing DNS libraries to understand implementation details.
As for the values, let us go back to the fields representation:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|0| => 256 (ZSK case)
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1| => 1 (SEP case)
|0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|1| => 257 (KSK case)
Bits 8-14 are always 0, as are the 0-6 ones.
SEP alone can't happen, so value 1 is not possible, 256 and 257 are the usual one for DNSSEC, and 0 (which means bit 7 is 0 so a key but "not DNSSEC case").
Remember that most (all?) of IETF protocols are MSB, left-most bit is most significant, so bit 15 is 2⁰, bit 14 is 2¹, etc. from right to left up to bit 0 at left which encodes 2¹⁵.
You can find that repeated in RFC 1035 §2.3.2:
Whenever an octet represents a numeric quantity, the left most bit in
the diagram is the high order or most significant bit.
[..]
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.
When I try to write the authentication key to the device using
mmc rpmb write-key /dev/mmcblk0rpmb /opt/data/keyfile.txt
or
echo -n AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH | mmc rpmb write-key /dev/mmcblk0rpmb -
I get the following error message
RPMB operation failed, retcode 0x0001
Do you know that the reason could be?
Have you solved this problem?
In Embedded Multi-Media Card (e•MMC) Electrical Standard (5.1)
6.6.22.4.1 Programming of the Authentication Key
The Authentication Key is programmed with the Write Multiple Block command, CMD25. Prior to the command CMD25 the block count is set to 1 by CMD23, with argument bit [31] set as 1 to indicate Reliable Write type of programming. If block count has not been set to 1 and/or argument bit [31] has not been set to 1 then the subsequent Write Multiple Block command must fail and General Failure shall be indicated.
Does it help?
I have a ZFS pool with the following layout and errors:
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x5000039ff3d3b114-part2 ONLINE 0 0 0
wwn-0x5000039ff4d3b513-part1 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
wwn-0x5000c500a42783bc-part1 ONLINE 0 0 2
wwn-0x5000c500a426d50b-part1 ONLINE 0 0 2
errors: Permanent errors have been detected in the following files:
tank/foo/bar#veryOldSnapshot;corruptFile.qcow2
So it looks as if on two different devices the same record has been corrupted at the same time. The data in question is on this disks since 2019 and the pool is scrubbed every week. How are the chances? IMHO this cannot be a real "bits are flipped due to cosmical radiation or hdd failure" case, because the probability that exactly the same blocks are corrupted on both disks and no other block is are really low.
What else can have caused this? I ran memtestx86 without problems and scrubbing again does not find any other errors. However since the block is used in a long chain of snapshots, even removing the snapshot in question does just make the problem move to the next snapshot.
I recently encountered the following problem:
Give a Turing machine diagram for a Turing machine that on input a string x ∈ {0, 1}∗ halts (accepts) with its head on the left end of the tape containing the string x′ ∈ {0, 1}∗ at the left end (and blank otherwise) where x′ is the successor string of x in lexicographic order; i.e. the next string in the sequence ε, 0, 1, 00, 01, 10, 11, 000, . . . in which the strings are listed in order of increasing length with ties broken by their corresponding integer value. (Briefly document your TM.)
I am confused as to how to start designing an appropriate solution for it. Could I get a couple of pointers for firstly designing this machine, and then Turing machines in general?
Turing Machines
First off, you need to understand what a Turing machine is, and by Turing machine, I'm assuming you're talking about a Universal Turing Machine. This is a conceptual machine created by the Godfather of Computer Science, Alan Turing.
The machine is built up of some components. First, an infinite tape that contains input. Something like..
1-0-1-1-1-1-0-1-0-1-0
Then a set of rules..
if 1 then 0
if 0 then 1
So when the machine hits the 1, the output is 0, as per the rule. We define the machine hitting a value when the read head is set to it. The read head is like the current position in the turing machine. So it will go..
1-0-1-1
^------------Current head.
Then the next iteration:
1-0-1-1
^----------Current Head
This machine is actually simulating bitwise NOT functionality. You can also set a state in a turing machine, so for example:
if 1 then enter state 1
if 0 then enter state 0
Big deal right? Example suddenly, now you can do stuff like:
1. if 1 and in state 1 output 1 and enter state 0
2. if 1 and in state 0 output 0 and enter state 1
3. if 0 and in state 0 output 1 and enter state 1
4. if 0 and in state 1 output 0 and enter state 0
And we define a state as our default state. In this example, let's call it state 0. So when the machine starts, it sees a 1. Well I'm in state 0 and I've just got a 1 so I'm going to do rule number 2. Output a 0 and enter state 1. The next number is a 0. Well I'm in state 1, so I call rule number 4. See where this is going? By adding states, you really open up what you can do.
Now, a Universal Turing Machine is what's known as Turing Complete. This means that it can compute any computable sequence. Including, the specification for your assignment!
Your Assignment
So let's look at your assignment in the context of a turing machine.
The aim of the machine is to print out..
0 1 00 01 11 000 001 011 111
So we know that we need to maintain a state. We also know that the state needs to get deeper and deeper. So if you user types in 000, we need to be able to know that we have three characters to output.
And in terms of homework help, that's I'm afraid all I should be responsibly giving you. A good understanding of the turing machine, plus an understanding of what you need this to do, should result in a start in your research to a solution.
Here's a dump of the stats provided my mod_pagespeed from one of my sites.
resource_url_domain_rejections: 6105
rewrite_cached_output_missed_deadline: 4801
rewrite_cached_output_hits: 116004
rewrite_cached_output_misses: 934
resource_404_count: 0
slurp_404_count: 0
total_page_load_ms: 0
page_load_count: 0
resource_fetches_cached: 0
resource_fetch_construct_successes: 45
resource_fetch_construct_failures: 0
num_flushes: 947
total_fetch_count: 0
total_rewrite_count: 0
cache_time_us: 572878
cache_hits: 872
cache_misses: 1345
cache_expirations: 242
cache_inserts: 1795
cache_extensions: 50799
not_cacheable: 0
css_file_count_reduction: 0
css_elements: 0
domain_rewrites: 0
google_analytics_page_load_count: 0
google_analytics_rewritten_count: 0
image_inline: 7567
image_rewrite_saved_bytes: 208854
image_rewrites: 34128
image_ongoing_rewrites: 0
image_webp_rewrites: 0
image_rewrites_dropped_due_to_load: 0
image_file_count_reduction: 0
javascript_blocks_minified: 12438
javascript_bytes_saved: 1173778
javascript_minification_failures: 0
javascript_total_blocks: 12439
js_file_count_reduction: 0
converted_meta_tags: 902
url_trims: 54765
url_trim_saved_bytes: 1651244
css_filter_files_minified: 0
css_filter_minified_bytes_saved: 0
css_filter_parse_failures: 2
css_image_rewrites: 0
css_image_cache_extends: 0
css_image_no_rewrite: 0
css_imports_to_links: 0
serf_fetch_request_count: 1412
serf_fetch_bytes_count: 12809245
serf_fetch_time_duration_ms: 28706
serf_fetch_cancel_count: 0
serf_fetch_active_count: 0
serf_fetch_timeout_count: 0
serf_fetch_failure_count: 0
Can someone please explain what all of the stats mean?
There's a lot of stats here. I'm going to just describe a few of them, because this will get long. We should probably add detailed doc. I can follow-up with more answers later if these are useful.
resource_url_domain_rejections: 6105: this means that since your server restarted, mod_pagespeed has found 6105 resources that it's not going rewrite a resource because their domains are not authorized for rewriting with the ModPagespeedDomain directive. This is common & occurs anytime time someone refreshes a page with a twitter, facebook, or google+ widget.
rewrite_cached_output_missed_deadline: 4801: when a resources (e.g. a jpeg image) is optimized, it happens in a background thread, and the result is cached so that subsequent page views referencing the same refresh are fast. To avoid slowing down the first view, however, we use a 10 millisecond timer to avoid slowing down the time-to-first byte. This stat counts how many times that deadline was exceeded, in which case the resource is left unchanged for that view, but the optimization continues in the background & so the cache is written.
rewrite_cached_output_hits: 116004: counts the number of times we served an optimized resource from the cache, thus avoiding the need to re-optimize it.
rewrite_cached_output_misses: 934: counts the number of times we looked up a resource in our cache and it wasn't there, forcing us to rewrite it. Note that we would also rewrite a resource that was in the cache, but whose origin cache expiration-time had expired. E.g. if your images had cache-control:max-age=600 then we would re-fetch them every 10 minutes to see if they've changed. If they have changed we must re-optimize them.
num_flushes: 947: this is the number of times the Apache resource-generator for the HTML (e.g. mod_php or Wordpress) called the Apache function ap_flush(), which causes partial HTML to be flushed all the way through to the user's browser. This is interesting for mod_pagespeed because it can limit the amount of optimization we can do (e.g. we can't combine CSS files whose elements are separated by a Flush).
cache_time_us: 572878 - the total amount of time, in microseconds, spent waiting for mod_pagespeed's HTTP Cache (file + memory) to respond to a lookup request, since the server was started.
I think that's enough for now. Are there specific other statistics you'd like to learn more about?
Most of these were created for us to monitor the health of mod_pagespeed as it's running, and to help diagnose users' issues. I have to admit we haven't used it much for that purpose, but we use them during development.